royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles
Date Sat, 14 Apr 2018 00:58:25 GMT
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 this
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 if
I then do "trace(element.className)" it will report the updated I
think both are synced by default

2) Now Button has two new methods that must make various operations with
arrays (join, push, splice...), this means in almost all jewel components
override at least computeFinalClassNames and insert new custom methods for
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

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

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 className should
be used by users only at init time and then use the rest of classList

The only difference for me is that you want to avoid the classList initial
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 className"
and frameworks like MDL that are based only on classList , and all jsperfs
(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 do
what they want, although we say "use className only at init time".

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 as
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

5) If I use that solution for jewel, I should introduce some intermediate
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 components.
And by doing that, as I said before, I'll prefer to remove that complexity
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 even
more convinced that we should use classList without any rejection. Even for
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 performance
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 one).
For Jewel, I can bet for the same method MDL uses with classList and as I
must to refactor half of the Jewel components to extend from UIBase
directly instead of Basic components counterparts, I can put a JewelUIBase
piece between that uses classList in the way Jewel need. In fact Jewel, and
any of the modern UI sets (Semantic, MDL, Bootstrap, ...) depends heavily
in class selector assignation, hence the use of classList as a general
rule. So I think is natural to have this marked differentiation, while in
Basic we should not expect people wants to deal with class selectors in a
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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message