On 2/23/18, 8:50 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:

>Just the opposite. The typeNames get rid of everything what is setup in
>the
>classList.
>
>But className is being add typeNames. This is what is happen:
>
>typeNames=mdl-card
>classList.add("someclass")
>
>In addedToParent:
>className += typeNames
>classList is being wipped out and filled by className.
>
>That is ok?

I don't know if that is "ok", but that is expected because you are
manipulating element.classList directly but element.classList is mapped to
className + typeNames.

Here's a rough analogy:  If you have an ArrayList wrap and track an Array
and then directly manipulate the Array, you can't guarantee that the
ArrayList will still track the array.

UIBase wraps an HTMLElement.  The APIs on UIBase are supposed to be
proxied into the element.  If you manipulate the element directly, you
have to sync up the wrapper's properties.

Either work with the UIBase APIs to get the classList you want, or after
manipulating classList, update classNames as needed so the next setting of
className or the addToParent call does not disturb your manipulated
classList.

-Alex
>
>On Fri, Feb 23, 2018, 17:26 Alex Harui <aha...@adobe.com.invalid> wrote:
>
>> TypeNames is supposed to override what is in classList.  ClassList
>>should
>> contain two sets of names. Immutable ones that come from typeNames like
>> TextInput or Card that map to the component that is pointed to by
>> element.royale_wrapper.  That allows us to "extend" the set of
>> TypeSelectors as folks in Flex are used to.  Then the rest of the names
>>in
>> classList map to className that custom Views or the user can set.
>>
>> So if your code wants to manipulate classList directly, it might be
>>easier
>> to manipulate className, or else, re-populate classname after
>>manipulating
>> classList by updating className with everything other than what is
>> specified in typeNames.
>>
>> If you are saying that the shadow code is trying to get rid of whatever
>> was specified in typeNames, I suppose that's "ok" but that would be a
>>new
>> pattern.  It is more likely that if typeNames was set to Card that there
>> should be few if any properties in the Card selector that shadow should
>> affect.  There really shouldn't be a reason to kick the names in
>>typenames
>> out of the classList.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>> On 2/23/18, 8:16 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:
>>
>> >Reading what you are saying here regarding classList and className w
>>have
>> >a
>> >bug. typeNames shouldn't override what is inside classList, but this is
>> >what has happened in addedToParent.
>> >
>> >Am I understand you correctly?
>> >
>> >
>> >On Fri, Feb 23, 2018, 17:11 Alex Harui <aha...@adobe.com.invalid>
>>wrote:
>> >
>> >>
>> >>
>> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com>
>> wrote:
>> >>
>> >> >Alex,
>> >> >
>> >> >I have started to work on MDL and move all typeNames from
>> >>createElement to
>> >> >constructor. Unfortunately something is not right here.
>> >> >
>> >> >1) I still need to exclude BasicJS.swc:default.css - I did add
>>theme to
>> >> >MaterialDesignLite module maven build - it didn't help.
>> >> >2) If I cannot setup typeNames and classNames inside my component,
>>how
>> >>can
>> >> >I achieve switching some UI parts of the component ? In MDL it is
>>quite
>> >> >common that if I would like to change component I'm adding to it css
>> >> >class.
>> >> >[1] - This is the example. If I remove line it doesn't work. There
>>are
>> >> >several places in MDL where we are doing such things. It is common
>>in
>> >>JS
>> >> >world doing such things.
>> >>
>> >> That's because the JS world doesn't have strong typing.  They can
>> >> transform a TextInput into a TextArea and not care.  I suspect that
>>if
>> >>you
>> >> set shadow at runtime it won't have an effect because typeNames is
>>not
>> >> re-evaluated after adddedToParent.  The className property is
>>suppose to
>> >> combine with typeNames and result in the element.classList by setting
>> >>(in
>> >> addedToParent) the element.className to the space-separated list of
>> >> everything in typeNames and className.  So, if MDL code manipulates
>> >> element.classList, I think it should be echoing those changes into
>>the
>> >> className property, not typeNames.  typeNames should be considered
>> >> "write-once" or "write during constructor" and not changed
>>afterwards.
>> >>It
>> >> is the set of things that go in the element.classList that should be
>> >> immutable.  As immutable as declaring a true subclass.  className is
>>for
>> >> the things that go in element.classList that can change at runtime.
>> >>
>> >> My 2 cents,
>> >> -Alex
>> >>
>> >> >
>> >> >typeNames = element.className;
>> >> >
>> >> >Thoughts ?
>> >> >
>> >> >[1]
>> >> >
>> >>
>> >>
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.ap
>> >>a
>> >> >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com
>> >> %7C55b6f3b3cb1b40e46bf108d
>> >>
>> 
>>>>>57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549967805810
>>>>>82
>> >>>9&
>> >> >sdata=i9EZFYDPNqo4lakPPe1lB0NDfajXmqhMnDX7bxiBecc%3D&reserved=0
>> >> >
>> >> >Thanks,
>> >> >Piotr
>> >> >
>> >> >
>> >> >2018-02-23 15:55 GMT+01:00 Piotr Zarzycki
>><piotrzarzyck...@gmail.com>:
>> >> >
>> >> >> Peter,
>> >> >>
>> >> >> That is interesting what you are saying. What will happen then if
>>you
>> >> >>have
>> >> >> class which extends other one. The parent class is setting
>>typeNames
>> >>and
>> >> >> derived one also before super? The parent one will override it?
>> >> >>
>> >> >> I cannot check now how typeNames is implemented.
>> >> >>
>> >> >> Piotr
>> >> >>
>> >> >>
>> >> >> On Fri, Feb 23, 2018, 15:13 Peter Ent <p...@adobe.com.invalid>
>> wrote:
>> >> >>
>> >> >>> I have been guilty of this and have been using typeNames now.
>>I've
>> >> >>>found
>> >> >>> that I need to set typeNames before calling super() in the
>> >> >>>constructor. I
>> >> >>> thought it was done afterwards, but if I set typeNames after
>>calling
>> >> >>> super(), the typeName I set does not show up in the HTML
>>produced.
>> >> >>>
>> >> >>> Also, suppose I have this: A Menu with a label inside of it.
>>People
>> >> >>>will
>> >> >>> want to change the background color of the menu and the color of
>>the
>> >> >>> label's text. If I were doing this in plain HTML/JS/CSS, I would
>> >>set a
>> >> >>> selector:  .Menu .Label { color: blue; } but that's not
>>supported in
>> >> >>>the
>> >> >>> Flash Player. So when I set up the typeName for the label inside
>>of
>> >>the
>> >> >>> Menu should I set it to: Menu_Label or MenuLabel or Menu-Label?
>>And
>> >>is
>> >> >>> using "." in a selector name a good idea? I would think the CSS
>> >> >>>processor
>> >> >>> in the browser would be confused between ".x.y" and ".x .y" which
>> >>can
>> >> >>>also
>> >> >>> be written as ".x.y". Basically, we should have a consist naming
>> >> >>>pattern
>> >> >>> here.
>> >> >>>
>> >> >>> ‹peter
>> >> >>>
>> >> >>> On 2/23/18, 4:09 AM, "Gabe Harbs" <harbs.li...@gmail.com> wrote:
>> >> >>>
>> >> >>> >There¹s some edge cases which seem problematic. One example:
>> >> >>> >ComboBoxBiew has the following:
>> >> >>> >            input = new TextInput();
>> >> >>> >            input.className = "ComboBoxTextInput";
>> >> >>> >
>> >> >>> >            button = new TextButton();
>> >> >>> >            button.className =
>> >> >>> >"opt_org-apache.royale-html-ComboBox_Button";
>> >> >>> >
>> >> >>> >Input and button are both external to the view class, but are
>> >>managed
>> >> >>>by
>> >> >>> >the view class. On the other hand, there is a chance that the
>>user
>> >> >>>might
>> >> >>> >wan to style them. I¹m not sure whether className or typeNames
>>is
>> >>more
>> >> >>> >appropriate hereŠ
>> >> >>> >
>> >> >>> >Harbs
>> >> >>> >
>> >> >>> >> On Feb 23, 2018, at 11:03 AM, Gabe Harbs
>><harbs.li...@gmail.com>
>> >> >>> wrote:
>> >> >>> >>
>> >> >>> >> I¹ll help.
>> >> >>> >>
>> >> >>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui
>> >><aha...@adobe.com.INVALID
>> >> >
>> >> >>> >>>wrote:
>> >> >>> >>>
>> >> >>> >>> Quick note before I shut down for the night.
>> >> >>> >>>
>> >> >>> >>> UIBase has both a typeNames and className property.
>>TypeNames
>> >>is
>> >> >>>used
>> >> >>> >>>to
>> >> >>> >>> emulate Flex-like type selectors in the CSS lookup.  It
>>should
>> >>be
>> >> >>>set
>> >> >>> >>>in
>> >> >>> >>> the constructor and never set from outside the class.  There
>> >>are a
>> >> >>>few
>> >> >>> >>> classes in Basic and lots of classes in MDL that should be
>> >> >>>upgraded to
>> >> >>> >>>set
>> >> >>> >>> typeNames in the constructor.  Subclasses can append to the
>>base
>> >> >>> >>>class's
>> >> >>> >>> typeNames
>> >> >>> >>>
>> >> >>> >>> className is the opposite.  It should never be set inside the
>> >> >>> >>>component's
>> >> >>> >>> class.  It is for users of that component to set styles on
>>the
>> >> >>> >>>component.
>> >> >>> >>>
>> >> >>> >>> Can we get a volunteer to clean this up?
>> >> >>> >>>
>> >> >>> >>> Thanks,
>> >> >>> >>> -Alex
>> >> >>> >>>
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> >> >--
>> >> >
>> >> >Piotr Zarzycki
>> >> >
>> >> >Patreon:
>> >> >*
>> >>
>> >>
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> >> %7C55b6f3b3cb1b40
>> >>
>> 
>>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549
>>>>>96
>> >>>78
>> >>
>> 
>>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserv
>>>>>ed
>> >>>=0
>> >> ><
>> >>
>> >>
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> >> %7C55b6f3b3cb1b40
>> >>
>> 
>>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549
>>>>>96
>> >>>78
>> >>
>> 
>>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserv
>>>>>ed
>> >>>=0
>> >> >>*
>> >>
>> >>
>>
>>

Reply via email to