It seems like either you have missed some of the discussion or maybe we
weren't clear enough.

Simply put:
-The Basic components do not need to handle classList APIs.  There is no
expectation that classes will be frequently added and removed.
-The goal of most component sets in Royale is to abstract away the
underlying platform APIs.  That's why I'm not in favor of having a
classList API on UIBase.
-MXML is better with space delimited string lists instead of arrays.
-It doesn't make sense to split strings into an array in JS when the
browser clearly can do it.
-This perf test shows className is faster [1]
-So does this one [2]

We are starting from a list of strings.  MDL is not.  And that makes a
difference, IMO.

I forgot to mention earlier that I was not happy that addStyles and
friends were JS-only.  It would have been better if it did not take an
element since that is a JS platform implementation.  That way application
developers could use addStyles and friends to manipulate the set of class
selectors at runtime.

More comments in-line..


On 4/13/18, 7:18 PM, " on behalf of Carlos Rovira"
< on behalf of> wrote:

>I think the discussion now should center in numbers.
>I added "" to typedefs (how could we live without this
>until now? :))

>I think numbers are near identical right?
>So given very close numbers should make us choose the more simplest code
No.  Small samples are often not useful.  These kinds of arguments are the
ones that led to UIComponent being 13,000 lines in Flex.

>2018-04-14 2:58 GMT+02:00 Carlos Rovira <>:
>> Hi Alex,
>> just studied you changes and want to ask you a few things:
>> 1) Why className and classLists methods must remain unsynced? I think
>> is not necessary and seems to me a bit unnatural since when I add styles
>> though classList in a element this makes the internal list changed, and
>> I then do "trace(element.className)" it will report the updated
>> I
>> think both are synced by default

I proposed a way to have components that want to use classList pay for it.
 If you want to further penalize those components in order to maintain
synchronization of classList and className go ahead as long as it doesn't
impact org.apache.flex.core.UIBase.  Yes, the browser keeps className and
classList in sync, but you are missing that the emphasized, primary and
secondary selectors are not in the className list maintained by UIBase and
there is additional cost to doing so.

>> 2) Now Button has two new methods that must make various operations with
>> arrays (join, push, splice...), this means in almost all jewel
>> override at least computeFinalClassNames and insert new custom methods
>> add/toggle/remove and each one will make various operations: in the
>>case of
>> toggle will do a push or splice and then the normal classList toggle
>> operation.
It is probably possible to package up the code I added to Jewel Button and
make it re-usable without inserting a base class for all of Jewel.  Or is
absolutely every Jewel component going to need that code?  If so, then
maybe a common base class for all of Jewel makes sense.

Also, the code I added to Jewel Button is can be greatly simplified if you
assume folks will not directly set className after adding to parent.

>> 3) we are introducing a new array property per component to store what
>> classList already do

No, the array does not have to have as many elements as the classList.
>> So for me we are introducing lots of complexity, with more code splitter
>> in every class, each one with more operations of array operations that
>> finaly makes the same call I did. And generating complexity since
>> should be used by users only at init time and then use the rest of
>> classList apis...

That's PAYG.  The classes that need it get the additional complexity.  And
again, if we want to restrict setting classname after init in Jewel,
that's totally fine with me and will simplify the code.
>> The only difference for me is that you want to avoid the classList
>> add method that in most of the cases will add from 1 or 2 classes and
>>up to
>> 3-4-5. I think normal components would have 3 on average...
>> This related to lots of sites saying "use classList instead of
>> and frameworks like MDL that are based only on classList , and all
>> (that although are not reflecting our concrete use case and use of
>> classList, I think are completely valid on essence) makes me think about
>> how we have such different visions.
>> So I must to say that as much as I want to see the advantages the
>> approaches do not convince me...
>> for me is more simple that all of that.
>> 1) I think people have the APIs (className and classList) and can/will
>> what they want, although we say "use className only at init time".

Again, we are abstracting the underlying implementation of how to set
class selectors in most Royale component sets.  That way, if we want to
target other output we have fewer APIs to reproduce.  We only need to
reproduce the conceptual APIs.
>> 2) I think we should have the most easy way to modify since browsers are
>> takin care of internal apis performance (or at least I'm confident with
>> that, like I was confident on flash player performance)
>> 3) I don't like to introduce lots of code when maybe the basic usage of
>> classList can be even more efficient. I give various jsperf studies out
>> there but both Harbs and you didn't show me anyone that shows className
>> a better option.
>> 4) If we are introducing such complexity, wouldn't be better to remove
>> completely classList and end that code with the new array property and
>> array operations? I think it will be more performant and will remove
>> complexity.
>> 5) If I use that solution for jewel, I should introduce some
>> class between UIBase and a Jewel Component where I can proxy all that
>> methods that are now in button to avoid replicate in all jewel
>> And by doing that, as I said before, I'll prefer to remove that
>> and go for simple classList manipulation since is the same that MDL (to
>> name a concrete and successful project that renders and performs
>> magnificent) does [1] (I put button example just as an example since
>> there's lots more)
>> Sincerily, I'm not convinced with the results exposed here, and I was
>> always thinking that I was not seeing something evident, but now I'm
>> more convinced that we should use classList without any rejection. Even
>> the use of className in MXML, is ok since I proved you can transform it
>> without problem getting the string, splitting and introducing in the
>> classList, and then opertating with is when needed without any
>> significant problem. For me is more problematic all the code we want to
>> introduce to avoid possible performance problems that I and many others
>> don't see and that main web projects actually don't see and are used all
>> over the web. We should not be different in something that other has
>> already adopted, and if people is using it, is because the browsers, the
>> standards and all the web wants all people using it, and for me is what
>> happen with classList.
>> in resume. I still don't want to make this discussion longer. I think we
>> have different opinions on this particular subject and the greatness of
>> royale is that it doesn't mind since if you and Harbs are betting for
>> className, we can remain Basic with the initial use (or the current
>> For Jewel, I can bet for the same method MDL uses with classList and as
>> must to refactor half of the Jewel components to extend from UIBase
>> directly instead of Basic components counterparts, I can put a
>> piece between that uses classList in the way Jewel need. In fact Jewel,
>> any of the modern UI sets (Semantic, MDL, Bootstrap, ...) depends
>> in class selector assignation, hence the use of classList as a general
>> rule. So I think is natural to have this marked differentiation, while
>> Basic we should not expect people wants to deal with class selectors in
>> heavy use.
>> Maybe I can wrong, but sincerely, if so I can't see where, but I firmly
>> believe in that, and for me is a clear definition of Jewel needs.
>> Thoughts?

My proposal lets our MDL and Jewel components use classList heavily in a
PAYG way.  It can be simplified if we are going to restrict setting of
className after adding to the DOM.  If you want to see what the code looks
like with that assumption try making the changes or I will do it.

I think we have proof that className is faster for when we want to use it
at init time.  I would like to see if we can create APIs for manipulation
the classList at runtime that isn't JS-only and asssumes there is an
element so folks can use those APIs at runtime instead being tempted to
change className.

My 2 cents,
>Carlos Rovira

Reply via email to