royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: TypeNames vs ClassName
Date Mon, 12 Mar 2018 18:27:04 GMT
HI Alex,

ok, I think I'll be subclassing in my branch and see where I get, in this
way the Piotr and Harbs can continue with things as they expect to.
In the other way, maybe it could seem that I'm worried to much about how
html looks, and maybe things like the layouts can wait, but I think is
important
to get some structural points set in a concrete way in order to grow from
there in a better way. As I progress in my journey to get all this pieces
ok I feel more confortable, and
I think, having a good foundation with only 1 or 2 components (like button,
textbutton,...) then will make me go fast with the rest of components

thanks

2018-03-12 19:09 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:

> Hi Carlos,
>
> I think people are more uncomfortable with the proposal to use
> element.classList than any issue about order.  It is hard for me to truly
> understand without seeing code so I think you should push it to your
> branch.
>
> I agree with Piotr that we can't make the users (app dev) use classList.
> Folks are going to use className out of habit or because they are
> borrowing a code snippet from the web.
>
> But most important, real users like Alina need components that work and
> I'm not convinced she's going to look under-the-hood.  It is frustrating
> to me that we have lots of emulation components to write but instead we
> are discussing details of typeNames and classNames.  IMO, it just isn't as
> important.  If it isn't broken, don't fix it.  Learn to live with some
> imperfections.  The big picture is that migration has to work.
>
> Your work on having a default look is important because that will be the
> default look for Alina's and others apps, but again, I don't agree that it
> is important to make the underlying implementation perfect.  Nobody will
> even look under the hood unless there are enough emulation components that
> have a chance of working, even imperfectly.
>
> My 2 cents,
> -Alex
>
> On 3/12/18, 10:58 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >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 <aharui@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.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@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 <piotrzarzycki21@gmail.com>:
> >> >
> >> >> 2018-03-12 17:14 GMT+01:00 Alex Harui <aharui@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.rovira@gmail.com on behalf of Carlos
> >> >> Rovira"
> >> >> > <carlos.rovira@gmail.com on behalf of carlosrovira@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
> >><carlosrovira@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
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C48f27c30c67043b293dc08d5
> >8842eaa7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636564743347476990&s
> >data=Yb3%2BZPcjpyWFVsc4jcvK9u3QjQl%2FHe%2F%2BiWjgL5ccry4%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

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