Hi Alex,
since Piotr and Harbs seems not to be very comfortable with the change, I
can subclass UIBase for Jewel and make that changes there. I don't want to
conflict in such central point of the framework,
Will it be ok for all of us?
2018-03-12 18:56 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> IMO, the order isn't going to make or break Royale. Leave it as you have
> it and we'll see what our users think.
>
> -Alex
>
> On 3/12/18, 10:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
> >Hi
> >
> >sorry guys, I changed it since I thought I would not matter anyone. For me
> >is just the opposite. Feels very strange to me see things right to left,
> >is like description of folders, bread crumbs and something like this that
> >use to be from parent to child, and left to right
> >
> >I do that as well since for example Harbs said doesn't mind how final code
> >looks, but for me is important.
> >
> >do you want I reverse the commit? Is there a way to make it configurable
> >and be all happy? maybe I should subclass UIBase fo Jewel...
> >
> >
> >2018-03-12 18:01 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>:
> >
> >> 2018-03-12 17:14 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> >>
> >> > If HTMLElement.classList is exposed to the user (the app developer)
> >>then
> >> > they can remove any of the items that were added from the typenames.
> >> > There is no way to enforce immutability of the typenames. We can
> >>choose
> >> > to give up on that and require that app developers be careful, but I'd
> >> > rather not.
> >> >
> >> > Given that, if you've found a way to eliminate the need for
> >>CSSClassList,
> >> > that's great.
> >> >
> >> > IMO, the immutable things from typenames should be last in the list.
> >>My
> >> > eye reads left to right and doesn't want to have to skip over stuff
> >>that
> >> > will be the same.
> >> >
> >> >
> >>
> >> *TOTALLY *agree with that. I tend to omit stuff because it looks the
> >>same,
> >> so having typedefs at the beginning makes it so like that.
> >>
> >> Piotr
> >>
> >>
> >>
> >> > My 2 cents,
> >> > -Alex
> >> >
> >> > On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> Rovira"
> >> > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
> >> >
> >> > >Hi
> >> > >
> >> > >I made some simplification that works ok in Jewel:
> >> > >
> >> > >1.- remove CSSClassList and use element.classList since is native and
> >> > >supported in all browsers we target, this simplifies code, and
> >>removes
> >> > >classes from core.
> >> > >2.- I still need to use some additional code that can be simplified.
> >>I'm
> >> > >doing:
> >> > >
> >> > >element.classList.toggle("primary", value);
> >> > >setClassName(computeFinalClassNames());
> >> > >classList has its own toggle function that makes super easy to manage
> >> adds
> >> > >and removes, so no need to have a custom function in royale
> >> > >
> >> > >that uses:
> >> > >
> >> > >COMPILE::JS
> >> > >override protected function computeFinalClassNames():String
> >> > >{
> >> > >return super.computeFinalClassNames() + " " + element.classList;
> >> > >}
> >> > >
> >> > >I'd like to remove that and change the "setClassName" call to
> >>nothing,
> >> if
> >> > >we change UIBase to simple use classList
> >> > >
> >> > >My guess is that we can have "typenames" and "classNames" but once
> >>all
> >> > >set,
> >> > >all can be managed with classList to add/remove since this is native
> >>and
> >> > >manages all itself
> >> > >
> >> > >thoughts?
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >2018-03-12 14:01 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> long thread and very useful read here. Since Jewel is very similar
> >>to
> >> > >>MDL
> >> > >> in adding/removing classes I want to comment here some things:
> >> > >>
> >> > >> 1.- I just changed jewel typenames to the constructor and things
> >>works
> >> > >>ok,
> >> > >> I could remove the createElement override
> >> > >> 2.- I have into account the use of typenames as something inmutable
> >> (as
> >> > >> part of definition of a component) and classNames as things that
> >>are
> >> > >>put by
> >> > >> developer, or change at runtime due to some user operation
> >> > >>
> >> > >> Then:
> >> > >>
> >> > >> 3.- Why not use classList [1] instead of create our own
> >>CSSClassList ?
> >> > >>is
> >> > >> well supported in the browsers we are targeting
> >> > >>
> >> > >> Something more "light" :)
> >> > >>
> >> > >> 4.- I know that order in html classes are not relevant, in the
> >> > >>execution.
> >> > >> And most of people here doesn't mind if typenames are before or
> >>after
> >> > >> classNames. So hope this doesn't make any problem to anyone here:
> >> > >> Can I change the code to put typeNames before classNames in
> >> > >> computeFinalClassNames? I think this not affects anyone since is a
> >> small
> >> > >> change and helps me to get organized classnames and identify
> >>things. I
> >> > >> think is better to see in final html typeNames first then
> >>classNames
> >> so
> >> > >> "inheritance" (to call it some way), could be easy detected by the
> >>eye
> >> > >>
> >> > >> Thanks
> >> > >>
> >> > >> Carlos
> >> > >>
> >> > >>
> >> > >> [1]
> >> > >>https://na01.safelinks.protection.outlook.com/?url=
> >> > https%3A%2F%2Fwww.w3sc
> >> > >>hools.com%2FJsref%2Fprop_element_classlist.asp&data=02%
> >> > 7C01%7Caharui%40ad
> >> > >>obe.com%7C5fee37306b5f47f8664608d588305aef%
> >> > 7Cfa7b1b5a7b34438794aed2c178de
> >> > >>cee1%7C0%7C0%7C636564663624913122&sdata=EjW00lpVegbpFVp2%2FzQz%
> >> > 2FQZnsNcB1
> >> > >>G6R%2BkMSMIjboX0%3D&reserved=0
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Carlos Rovira
> >> > >>
> >> > >>https://na01.safelinks.protection.outlook.com/?url=
> >> > http%3A%2F%2Fabout.me%
> >> > >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> > 7C5fee37306b5f47f8664608
> >> > >>d588305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> > 7C63656466362491312
> >> > >>2&sdata=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%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%
> >> > 7C5fee37306b5f47f8664608d5
> >> > >88305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> > 7C636564663624913122&s
> >> > >data=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%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
> %7C8e98630662af
> >>4b9ed47f08d58841af24%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365647
> >>38054334432&sdata=PJK7MaYG0xHFDAxjz991NV%2B20a9mdDVBpyU3LVkbQZQ%3D&
> reserv
> >>ed=0
> >>
> >><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> %7C8e98630662af
> >>4b9ed47f08d58841af24%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365647
> >>38054334432&sdata=PJK7MaYG0xHFDAxjz991NV%2B20a9mdDVBpyU3LVkbQZQ%3D&
> reserv
> >>ed=0>*
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C8e98630662af4b9ed47f08d5
> >8841af24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636564738054334432&s
> >data=8IcBMe9DSVOSXFUS%2BzV36EGjyXlix%2FLL8udleSOv3WY%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
