I integrated the same pattern in Jewel's Button, CheckBox, RadioButton and Slider. This indicates that it can be implemented in a common base class for these components. The example looks ok to me.
The code assumes positioner. For Button, if there is no hierarchy, then positioner and element should be the same so it should work. If it turns out there are still going to be exceptions that don't work, then we might need to introduce a "styleTarget" property in the Jewel base class that createElement can assign and ClassSelectorList will use instead of positioner. HTH, -Alex On 4/16/18, 9:46 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: >Hi Alex, > >for me is ok to have it in JewelUIBase, >in the other hand to look at what I tried to say with "positioner" vs >"element" to apply class selectors, take a look at Jewel CheckBox (that >will be refactored to extend JewelUIBase instead of current Basic >CheckBox, >like the rest of components). In create element the element in an input >and >the positioner is a label so setClassName is overriden to apply styles to >positioner > >COMPILE::JS > override protected function setClassName(value:String):void > { > addStyles(positioner, value); > } > >in contrast Button will be using element instead since there's no wrapper. >Button is its own wrapper > >thanks > > >2018-04-16 18:27 GMT+02:00 Alex Harui <[email protected]>: > >> Hi Carlos, >> >> Again, let's be specific and not over-state the scenarios. I do not >> believe that absolutely all JS development is focused on class >>selectors, >> otherwise there would be more articles about that practice. And, while >>I >> don't doubt that the "setting properties that affect visuals" might need >> to access elements instead of just the positioner, I would expect the >> component to be an abstraction to the developer so when they choose "a >>set >> of groups of styles" it would always apply to the positioner. They >>should >> not have to know the internal "sub-DOM" of the component. >> >> After thinking about it more, I agree with Piotr that ClassListSelector >> should not be baked into UIBase. Your recommendation that it should be >> implies that you are still thinking in the Flex mindset. In Royale, >>PAYG >> is an important principle, and your arguments below basically describe >> "just-in-case" which is not PAYG. It might be that a JewelUIBase would >> integrate ClassListSelector. I will try to code that up today so we can >> see how that feels. >> >> Royale does want to make things easy, but, IMO, PAYG is more important >> than easy. Flex put easy as more important than PAYG, and while that >> might have helped Flex gain popularity more quickly, in the end, Flex >> began having size and performance problems. I do not want to repeat >>that >> mistake with Royale. It doesn't matter how easy it is to get started if >> you can't finish. There has to be the right balance. >> >> My 2 cents, >> -Alex >> >> On 4/16/18, 4:33 AM, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi, >> > >> >ClassListSelector could be ok, but think that depending on the >>components >> >in both MDL and JEWEL the class selector names added/removed/toggled >>could >> >go to positioner or to element. There's various examples of this in >>each >> >library. We should not lost that capability since is key. >> > >> >In order to bake in UIBase, my opinion is that devs will use this a >>lot in >> >their apps, so for me I'm ok to have it. >> >If it was an API partially used, I'd think about it, but actual JS >> >development is so much focused in add/remove class selectors. >> > >> >I'll be waiting for the final touches >> > >> >thanks Alex for working on this, and sorry if I'm a bit focused but I >> >think >> >this point is important since in Royale we try to make easy things and >> >encapsulate best practices and code, and this seems to me something >>that >> >people will use in library APIs and in final Apps >> > >> >thanks >> > >> > >> > >> >2018-04-16 10:18 GMT+02:00 Piotr Zarzycki <[email protected]>: >> > >> >> If I could decide - that class should be used as an util outside >>UIBase. >> >> UIBase should be as much technology agnostic as we can. However how >>to >> >>use >> >> that class outside ? >> >> >> >> Thanks, >> >> Piotr >> >> >> >> 2018-04-16 10:08 GMT+02:00 Alex Harui <[email protected]>: >> >> >> >> > Hi Carlos, >> >> > >> >> > I'm running out of ways to try to explain this one concept. >>Here's my >> >> > next attempt: I think you are too focused on the underlying >>browser >> >> > implementation. Conceptually, the application developer is >>"setting >> >> > properties to affect visuals" or "choosing sets of groups of >>styles at >> >> > runtime". That is the abstraction/APIs Royale needs to present. >>It >> >>has >> >> > nothing to do with className/classList. If we ever target some >>other >> >> > runtime, for example, native C code, or even in the SWF >> >>implementations, >> >> > there may not be any className/classList in the runtime and the >> >>runtime >> >> > implementation should only have to implement the APIs we present, >>and >> >>not >> >> > emulate the browser's className/classList. >> >> > >> >> > Thus, the APIs we present should be things like "primary", >> >>"secondary", >> >> > "emphasized" as "properties that affect visuals", and addStyles, >> >> > removeStyles, toggleStyles for "choosing sets of groups of styles". >> >>But >> >> > addStyles, removeStyles, and toggleStyles should not take an >> >>HTMLElement >> >> > as a parameter, but rather, an IUIBase. The key question here is >> >>whether >> >> > the JS implementation can always assume that the styles get >>applied to >> >> the >> >> > positioner which may not be the same as the element. I think the >> >>answer >> >> > is yes. >> >> > >> >> > Then we have another option, which is to say that there is "an >>initial >> >> set >> >> > of styles". That's our MXML className property. We are not >> >>obligated to >> >> > allow it to be changed at runtime since we have the other APIs nor >> >>are we >> >> > obligated to keep it in sync with the properties we use in the JS >> >> > implementation. Note that Royale className and HTMLElement >>className >> >>has >> >> > never been kept in sync even in Basic because we add typeNames. >> >> > >> >> > I think with that set of 3 categories, there isn't really a need >>for >> >> folks >> >> > to have to "totally reset the initial set of styles", which implies >> >> > setting MXML className at runtime, or if there is a small amount of >> >>code >> >> > to do it but it is computationally expensive, that may be >>acceptable. >> >> I >> >> > think "totally resetting" is a rare occurrence and the "choosing >> >>sets" is >> >> > a sufficient API. >> >> > >> >> > I spent this evening trying a different implementation, but found >>out >> >> that >> >> > classList isn't backed by the kind of data structure I thought it >> >>had. I >> >> > was hoping that toggle disabled entries instead of removing them. >> >>I've >> >> > pushed a first cut at another way of managing the list of classes >>by >> >> > trying to track the indexes in the classList set by the classname. >> >>See >> >> > ClassSelectorList.as. I haven't wired it up yet to Jewel. I'm >> >>pondering >> >> > whether it could go in UIBase. >> >> > >> >> > Thoughts? >> >> > -Alex >> >> > >> >> > >> >> > >> >> > >> >> > On 4/15/18, 4:01 AM, "[email protected] on behalf of Carlos >> >> Rovira" >> >> > <[email protected] on behalf of [email protected]> >>wrote: >> >> > >> >> > >Hi Alex, >> >> > > >> >> > >app devs will create logic that will use our encapsulated code >>(i.e: >> >> > >setting primary to true or false). Jewel as MDL has properties >>that >> >>uses >> >> > >to >> >> > >deal with true/false values to make it easy for the user to >>change a >> >> > >style. >> >> > >Under the hood, that is changing the "element.class" or >> >> > >"positioner.class". >> >> > >I think component's royale className property should be updated >>and >> >>not >> >> > >remain dirty since that would create lots of confusion for our >> >>users. If >> >> > >we >> >> > >do that folks should never operate again with "className", maybe >>it >> >> could >> >> > >not be a problem, although left className in a non valid state >>sound >> >> > >strange to me. If you think it can work, we can try it and see >>what >> >> > >happen... but seems to me that maybe we're making thing very >>complex >> >> when >> >> > >all could be more straight lined. Anyway, I'll wait for your >>changes. >> >> > >Thanks! >> >> > > >> >> > >Carlos >> >> > > >> >> > > >> >> > > >> >> > >2018-04-15 8:49 GMT+02:00 Alex Harui <[email protected]>: >> >> > > >> >> > >> IMO, Carlos still isn't understanding my point. My point is >>that >> >>the >> >> > >>app >> >> > >> devs will not need to be setting className. They will be >>setting >> >> > >> properties like "emphasized", "secondary" and "primary" that >>can do >> >> > >> whatever it wants under the covers, and if we assume that folks >> >>will >> >> not >> >> > >> set (or are not supposed to set) className after init time, >>there >> >>are >> >> > >>much >> >> > >> simpler ways to handle this situation. >> >> > >> >> >> > >> That said, I have another idea about how to allow "emphasized", >> >> > >> "secondary" and "primary" to use classList that might be simpler >> >>that >> >> > >>what >> >> > >> I have committed so far. I will try to code it up tomorrow for >> >>others >> >> > >>to >> >> > >> look at. >> >> > >> >> >> > >> Thanks, >> >> > >> -Alex >> >> > >> >> >> > >> On 4/14/18, 9:24 AM, "Piotr Zarzycki" >><[email protected]> >> >> > wrote: >> >> > >> >> >> > >> >Are you saying that it will work with your implementation and >>not >> >> with >> >> > >> >Alex's? >> >> > >> > >> >> > >> >Actually as a app developer above situation is very rare. >> >> > >> > >> >> > >> >Thanks, >> >> > >> >Piotr >> >> > >> > >> >> > >> >On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira >> >><[email protected] >> >> > >> >> > >> >wrote: >> >> > >> > >> >> > >> >> That's what Alex want. To make className only used at init >>time >> >> then >> >> > >>we >> >> > >> >> should use classList methods. >> >> > >> >> I think that the premises are not right, since Alex thinks >>devs >> >> will >> >> > >>not >> >> > >> >> make heavy use of switching class selectors at runtime (at >>init >> >> time >> >> > >>and >> >> > >> >> later while using the app). MDL and Jewel are constantly >>setting >> >> and >> >> > >> >> removing class selectors from elements and positioners, so >> >> className >> >> > >> >>(set >> >> > >> >> only once at init time) is not right for use, but for people >> >>using >> >> > >> >>Basic. >> >> > >> >> Hence, Basic should remain with className, and MDL/Jewel >>should >> >>go >> >> > >> >> classList *always* (shadowing it so will have a royale API to >> >>work >> >> > >>with >> >> > >> >>SWF >> >> > >> >> and JS and in JS compilation use classList >> >> > >> >> >> >> > >> >> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki >> >> > >><[email protected]>: >> >> > >> >> >> >> > >> >> > Carlos, >> >> > >> >> > >> >> > >> >> > Are you saying here having your idea: >> >> > >> >> > >> >> > >> >> > " >> >> > >> >> > 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". >> >> > >> >> > " >> >> > >> >> > >> >> > >> >> > If I do following things: >> >> > >> >> > >> >> > >> >> > <Component id="comp" className="myClass"/> >> >> > >> >> > >> >> > >> >> > And later in the code I do: >> >> > >> >> > >> >> > >> >> > comp.className = "myOtherClass"; >> >> > >> >> > >> >> > >> >> > It won't work? >> >> > >> >> > >> >> > >> >> > Piotr >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira >> >> > >><[email protected] >> >> > >> > >> >> > >> >> > wrote: >> >> > >> >> > >> >> > >> >> > > Alex >> >> > >> >> > > >> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui >> >><[email protected] >> >> >: >> >> > >> >> > > >> >> > >> >> > > > Carlos, >> >> > >> >> > > > >> >> > >> >> > > > It seems like either you have missed some of the >> >>discussion >> >> or >> >> > >> >>maybe >> >> > >> >> we >> >> > >> >> > > > weren't clear enough. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > I think most of what you say was considered but let's go >>for >> >> > >>parts: >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > Simply put: >> >> > >> >> > > > -The Basic components do not need to handle classList >> >>APIs. >> >> > >> >>There is >> >> > >> >> > no >> >> > >> >> > > > expectation that classes will be frequently added and >> >> removed. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > That's ok. Basic no, Jewel yes. That's huge diference, >>so I >> >> > >>think as >> >> > >> >> you >> >> > >> >> > > UIBase should go to Core and be as is now (or make the >> >>changes >> >> > >>you >> >> > >> >> > > estimate) >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > -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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > Right, classList is JS only so maybe an API in >>JewelUIBase >> >> > >>should be >> >> > >> >> > > general and use the JS code with COMPILE::JS >> >> > >> >> > > then implement others. >> >> > >> >> > > >> >> > >> >> > > -MXML is better with space delimited string lists >>instead of >> >> > >>arrays. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > I think in you version and my version is a string, but in >> >>mine >> >> > >>then >> >> > >> >>is >> >> > >> >> > > converted to feed classList >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > -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. >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > ok in Jewel we could do in that way, the main difference >> >>with >> >> > >>Basic >> >> > >> >>is >> >> > >> >> > that >> >> > >> >> > > the main task of this kind of set is >> >> > >> >> > > heavily deal with class selectors so for Jewel (not for >> >>Basic) >> >> we >> >> > >> >> should >> >> > >> >> > > focus on it what means to me be fundamental part of >> >>JewelUIBase >> >> > >>to >> >> > >> >>have >> >> > >> >> > an >> >> > >> >> > > API to deal with styles in all platforms and that all >> >> components >> >> > >> >> > extending >> >> > >> >> > > it can use. >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > 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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > ok, that's a fail on my implementation that should be >>fixed >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > More comments in-line.. >> >> > >> >> > > > >> >> > >> >> > > > [1] >> >> > >> >> > > > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> > >> https%3A%2F%2Fmeasuret >> >> > >> >>hat.net%2FBenchmarks%2FShow%2F54%2F0%2F&data=02%7C01%7Caharui% >> >> > >> 40adobe.com >> >> > >> >> >>>>%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de >> >> > >> cee1%7C >> >> > >> >>0%7C0%7C636593199085882368&sdata=ya1hbY9%2FHxLCMbEh% >> >> > >> 2BVqXP0OdWrV03zEPRAtu >> >> > >> >>ybj223w%3D&reserved=0 >> >> > >> >> > > > classname-vs-setattribute-vs-c >> >> > >> >> > > > lasslist >> >> > >> >> > > > [2] >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> > >> https%3A%2F%2Fjsperf.c >> >> > >> >>>>om%2Fclassname-vs-classlist-showdown%2F5&data=02%7C01%7Caharui% >> >> > >> 40adobe.co >> >> > >> >> >>>>m%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de >> >> > >> cee1%7 >> >> > >> >>C0%7C0%7C636593199085882368&sdata=ygYm8sTMDTniu1NFzxds3fEaa0e% >> >> > >> 2FxnNaYxHeO >> >> > >> >>6G3F0g%3D&reserved=0 >> >> > >> >> > > > >> >> > >> >> > > > On 4/13/18, 7:18 PM, "[email protected] on behalf >> of >> >> > >>Carlos >> >> > >> >> > > Rovira" >> >> > >> >> > > > <[email protected] on behalf of >> >> [email protected]> >> >> > >> >> wrote: >> >> > >> >> > > > >> >> > >> >> > > > >Hi, >> >> > >> >> > > > > >> >> > >> >> > > > >I think the discussion now should center in numbers. >> >> > >> >> > > > > >> >> > >> >> > > > >I added "performance.now()" to typedefs (how could we >> >>live >> >> > >> >>without >> >> > >> >> > this >> >> > >> >> > > > >until now? :)) >> >> > >> >> > > > >> >> > >> >> > > > Snip... >> >> > >> >> > > > > >> >> > >> >> > > > > >> >> > >> >> > > > >I think numbers are near identical right? >> >> > >> >> > > > > >> >> > >> >> > > > > >> >> > >> >> > > > >So given very close numbers should make us choose the >> >>more >> >> > >> >>simplest >> >> > >> >> > code >> >> > >> >> > > > > >> >> > >> >> > > > > >> >> > >> >> > > > >right? >> >> > >> >> > > > > >> >> > >> >> > > > No. Small samples are often not useful. These kinds >>of >> >> > >>arguments >> >> > >> >> are >> >> > >> >> > > the >> >> > >> >> > > > ones that led to UIComponent being 13,000 lines in >>Flex. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > I think here we are talking about performance, not about >>to >> >> > >>increase >> >> > >> >> > number >> >> > >> >> > > of lines of code >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > > >> >> > >> >> > > > > >> >> > >> >> > > > >2018-04-14 2:58 GMT+02:00 Carlos Rovira >> >> > >> >><[email protected]>: >> >> > >> >> > > > > >> >> > >> >> > > > >> 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 >> >> > >> >> > > > >>list...so 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. >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > That's because when I refactored the code when you ask me >> >>to do >> >> > >>so I >> >> > >> >> > tried >> >> > >> >> > > to make it >> >> > >> >> > > className dependent. I think the solution is in >>JewelUIBase >> >> wire >> >> > >>all >> >> > >> >> > > through classList. >> >> > >> >> > > we'll have a tiny performance hit, that's right, but I >> >>think a >> >> > >>uiset >> >> > >> >> with >> >> > >> >> > > the purpose of Jewel >> >> > >> >> > > (theming - styling - goof looking) is the price that >>have to >> >> > >>pay. a >> >> > >> >> > little >> >> > >> >> > > less performance than Basic >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> >> > >> >> > > > >> 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 >> >> > >> >> > > > >> 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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > Yes, all components in Jewel is doing/will do heavy use >>of >> >> style >> >> > >> >>API, >> >> > >> >> so >> >> > >> >> > is >> >> > >> >> > > a must >> >> > >> >> > > in this set to have that api (while it's not in UIBase >>and >> >> Basic) >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > 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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > No, as MDL, this kind of components are based on heavily >>add >> >> and >> >> > >> >> removal >> >> > >> >> > of >> >> > >> >> > > class selectors >> >> > >> >> > > users will pushing buttons, clicking checkboxes, and >>more, >> >>and >> >> > >>part >> >> > >> >>of >> >> > >> >> > that >> >> > >> >> > > actions will be to add/remove/toggle >> >> > >> >> > > class selectors in one or more components. >> >> > >> >> > > >> >> > >> >> > > That's what MDL does, that what Jewel does, and that's >>what >> >>any >> >> > >> >>actual >> >> > >> >> UI >> >> > >> >> > > set with focus on visuals will do >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > >> 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 >> >> > >> >> > > > >>className >> >> > >> >> > > > >> 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 classes that need get the additional complexity, but >>at >> >> > >>least we >> >> > >> >> need >> >> > >> >> > > to >> >> > >> >> > > proxy all that in JewelUIBase since *all* Jewel >>components >> >>will >> >> > >>use >> >> > >> >>the >> >> > >> >> > > same code >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> >> > >> >> > > > >> 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". >> >> > >> >> > > > >> >> > >> >> > > > 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 >> >> > >> >> > > > >>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 >> >> > >> >> > > > >> complexity. >> >> > >> >> > > > >> >> >> > >> >> > > > >> 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. >> >> > >> >> > > > >> >> >> > >> >> > > > >> 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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > Alex, I prefer you do this. My only requirements are: >> >> > >> >> > > >> >> > >> >> > > * Have a JewelUIBase instead of the same code in all >> >> components. >> >> > >> >> > > * As I said, className will not be untouched after >> >>addToParent. >> >> > >> >>That's >> >> > >> >> a >> >> > >> >> > > huge part in MDL and Jewel >> >> > >> >> > > both sets add/remove/toggle styles at runtime. So make >>the >> >> > >>changes >> >> > >> >> > > modifying that rule in your mind. >> >> > >> >> > > * Is critical for me that components extending doesn't >>have >> >>to >> >> > >>add >> >> > >> >>new >> >> > >> >> > > methods that should be abstracted >> >> > >> >> > > in JewelUIBase and we can use basic API calls since we >>are >> >> > >>talking >> >> > >> >> about >> >> > >> >> > > heavy use (or principal use) in >> >> > >> >> > > this kind of components set. >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > 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. >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > I think that's the clue. While Basic makes all the duty >> >>before >> >> > >>add >> >> > >> >>to >> >> > >> >> > > parent, MDL and Jewel are constantly >> >> > >> >> > > adding, toggling and removing class selectors, that why >>we >> >>must >> >> > >>put >> >> > >> >>a >> >> > >> >> > clear >> >> > >> >> > > line between how UIBase works >> >> > >> >> > > (mainly like it's now) and how Jewel works (using heavy >>use >> >>of >> >> > >> >> classList >> >> > >> >> > > since is its nature, and 'll get rid completely of >>className >> >> use >> >> > >> >> > internaly) >> >> > >> >> > > >> >> > >> >> > > I hope we are reaching to something here. Could you >>change >> >>the >> >> > >> >> > > implementation taking into account the differences >>discussed >> >> > >>here? >> >> > >> >> > > >> >> > >> >> > > thanks >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > >> >> > >> >> > > > My 2 cents, >> >> > >> >> > > > -Alex >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > > >> >> > >> >> > > > > >> >> > >> >> > > > >-- >> >> > >> >> > > > >Carlos Rovira >> >> > >> >> > > > >https://na01.safelinks.protection.outlook.com/?url= >> >> > >> >> > > > http%3A%2F%2Fabout.me%2 >> >> > >> >> > > > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> > >> >> > > > 7C9fbf7c0d5e994a9acb6008d5 >> >> > >> >> > > > >a1ae2520%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> > >> >> > > > 7C636592691687691520&s >> >> > >> >> > > > >data=TR5G34hZMVutbPgcwAzTtNlFR0mQb8 >> >> > quhoBewhsOnSc%3D&reserved=0 >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > -- >> >> > >> >> > > Carlos Rovira >> >> > >> >> > > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> > >> http%3A%2F%2Fabout.me% >> >> > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> > >> 7C18aef785013e484cfcf108 >> >> > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> > >> 7C63659319908588236 >> >> > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYP >> gYGKsAptIcLSQ%3D&reserved=0 >> >> > >> >> > > >> >> > >> >> > >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> -- >> >> > >> >> Carlos Rovira >> >> > >> >> >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> > >> http%3A%2F%2Fabout.me% >> >> > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> > >> 7C18aef785013e484cfcf108 >> >> > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> > >> 7C63659319908588236 >> >> > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYP >> gYGKsAptIcLSQ%3D&reserved=0 >> >> > >> >> >> >> > >> >> >> > >> >> >> > > >> >> > > >> >> > >-- >> >> > >Carlos Rovira >> >> > >https://na01.safelinks.protection.outlook.com/?url= >> >> > http%3A%2F%2Fabout.me%2 >> >> > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> > 7Cf4e0ef1e27e8407606cd08d5 >> >> > >a2c057b6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> > 7C636593869391543673&s >> >> > >data=6DkfBSCL%2BBi9EhqUKaAcEbY%2FVLCy2My8bBKS67oohNQ%3D&reserved=0 >> >> > >> >> > >> >> >> >> >> >> -- >> >> >> >> Piotr Zarzycki >> >> >> >> Patreon: >> >>*https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fwww.pat >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> %7C93bcdf89489c >> >>42d6ee0d08d5a38df0c7%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C6365947 >> >>52523975728&sdata=4k1dL%2B5BAj4r3ibPhjdqKjt% >> 2BxrDIn6EComwUUIv1d1M%3D&rese >> >>rved=0 >> >> >> >><https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fwww.pat >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> %7C93bcdf89489c >> >>42d6ee0d08d5a38df0c7%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C6365947 >> >>52523975728&sdata=4k1dL%2B5BAj4r3ibPhjdqKjt% >> 2BxrDIn6EComwUUIv1d1M%3D&rese >> >>rved=0>* >> >> >> > >> > >> > >> >-- >> >Carlos Rovira >> >https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2 >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C93bcdf89489c42d6ee0d08d5 >> >a38df0c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> 7C636594752523975728&s >> >data=3PcAzDxMYbYeiZus1byoKtVDc%2FkCPjq1X6hj%2BJm62Y4%3D&reserved=0 >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5a6cdf9a44824bf9426608d5 >a3b9aed9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636594940261497954&s >data=%2BTahOv1SHSBPV%2B0DZDw1b7u3gbApLDhLA8VyB%2BKkog0%3D&reserved=0
