Hi Harbs

2018-03-13 12:54 GMT+01:00 Harbs <harbs.li...@gmail.com>:

> > On Mar 13, 2018, at 1:48 PM, Carlos Rovira <carlosrov...@apache.org>
> wrote:
> >
> > Cause I'm dealing with this since 2016 with MDL?, if this is not enough
> > experience and time with an API, don't know what should I do to reflect
> > that is the part of Royale where I always move and maybe have the most
> > experience. I had to solve the problems that recently was solved by Alex
> > with themes in MDL when I reported it almost 2 years ago and finaly
> where a
> > bug, but at that time wasn't.
> What specifically are you referring to here? What problem are you trying
> to solve by changing the way class lists are handled?

in FlexJS list 26/11/2016 there 's a "[FlexJS] className manipulation", I
opened various problems to work with classNames when working in the MDL lib.
In that thread Josh Tynjala pointed to the classList solution, but at that
time we were targeting IE9 and was not an option.
In that thread and many others at that time I was having the same problems
we're having here about persistent classes, others that are "switchable"
and the last ones that are added by devs or users.
I'll end trying lots of things to solve the problem and finaly get to the
solution we have in MDL until some days ago Alex made changes and report
about the problem and Piotr made the changes in MDL. For me what I did at
that time always was a "hack" since I had to make very strange things to
support how MDL works (that's very near at how Jewel works, and maybe to
any other UI Set that wants to be *customizable* visuals). Now that
classList is no more a problem since we're targeting IE11, don't see the
problem to address this and solve it finaly to make it work as a framework

> >
> >> The general rule with live collections in general is to avoid them when
> >> possible. Collections need to be resolved which adds overhead. The less
> >> interactions with a DOM, the better. Native JS is almost always going to
> >> more efficient than browser/DOM APIs.
> >>
> >>
> > That's true, and I adhere to that mantra most of the times, but in this
> > case I think it's better, since:
> >
> > -Users will have a more easy way to do things (and that's one of the
> things
> > flex did really good)
> Can you give me an example where this makes a difference to users? (What
> “this” are you referring to?)

I'm referring with this to "the theme feature" effort, where we want to
easily change appearance in a Royale UI set.
Right now we need to implement for each control 2 methods like the
followings (code from MDL)

private function addOrRemove(classNameVal:String,add:Boolean):void
add ? _classList.add(classNameVal) : _classList.remove(classNameVal);
override protected function computeFinalClassNames():String
return _classList.compute() + super.computeFinalClassNames();

and use


In my Jewel class I only do this (no additional methods or overrides)

element.classList.toggle("primary", value);

and that's all :)

> > -If there's an impact in performance, my guess is that will be minimal
> (but
> > can ensure since I don't have the data)
> I understood that your point was performance, so I’m confused.

No, what I say is that the API is browser based so it should be performant
enough. And we're not talking in this case about a huge process to handle,
we're talking about manage collections of 1 to maybe 2 to 6 elements and
running in concrete parts. What makes the process very affordable.

> Maybe a list of the issues you are struggling with might help me
> understand better what you are trying to accomplish. (and allow me to help)

Hope the things mentioned before will count as the list. I think I posted a
lot in FlexJS and now in Royale.
Maybe If you don't see it is because you're not using it as I do, but think
in users that will more in the UX front.


> Thanks,
> Harbs

Carlos Rovira

Reply via email to