royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <greg.d...@gmail.com>
Subject Re: Revisiting the old debate: 'localId vs. id'
Date Fri, 02 Nov 2018 17:44:06 GMT
Hi Harbs, thanks for that feedback.

I do agree that using both localId and id is unlikely and should probably
cause a compiler error if used as it stands currently. Which one wins?
At the moment it is possible and id wins, so yes it would make sense for
the conflict to be a compiler error.

How many people are using legacy IDEs for Royale?
I still use IntelliJ, although I will try VSCode soon.

'I don’t think it’s a good idea to make id default to not creating DOM ids.
That would invalidate CSS for the id.'

How often in practice do you use external id targeting for css styling? I
think mostly it is class (className) based, isn't it?
I'm no expert on CSS styling, but my impression is that the use of ids for
styling in css is minimal (because it is specific).
If it is rare, then presumably it is not a lot of work to switch it on for
specific cases.

But the idea for defaults was more to let the default be configurable:
as-it-is now or opposite.

I've been doing React work for almost 18 months now, and in that experience
use of element level 'id' in jsx (which is propagated to DOM) is extremely
rare. Perhaps my experience is not representative, but it has also
influenced the way I think about this.
And React also has a different paradigm and has a more explicit notion of
local references being separate from 'id' in any case. I'm only mentioning
this to compare, I'm happy to be doing more actionscript/mxml :)




On Fri, Nov 2, 2018 at 10:09 PM Harbs <harbs.lists@gmail.com> wrote:

> I tend to like Greg’s suggestion, but I don’t feel strongly on the subject
> one way or another.
>
> I do agree that using both localId and id is unlikely and should probably
> cause a compiler error if used as it stands currently. Which one wins?
>
> I’ve actually never used localId, although I possibly should have. Taking
> VS Code as an example, it seems like there’s no code hinting for localId
> currently, but it is correctly verified when used. How many people are
> using legacy IDEs for Royale?
>
> I don’t think it’s a good idea to make id default to not creating DOM ids.
> That would invalidate CSS for the id.
>
> My $0.02,
> Harbs
>
> > On Nov 2, 2018, at 11:01 AM, Piotr Zarzycki <piotrzarzycki21@gmail.com>
> wrote:
> >
> > Hi Greg,
> >
> > I'm really happy that you are helping Carlos with that! He may move
> forward
> > much faster. I just have question to following:
> >
> > "-My understanding is that best practice is to avoid multiple identical
> ids
> > in the browser, irrespective of whether the browser is forgiving of that
> or
> > not. If so, it might be good to have at least an option to set the
> default
> > implementation to support 'best practice' (DOM ids 'off' by default, 'on'
> > explicitly, to avoid 'duplicate ids by accident'). Maybe some sort of
> > import wizard for a legacy flex project could do something like this in
> an
> > IDE by default though. But it could be a compiler config thing too
> perhaps."
> >
> > Does your idea is saying that if I have some Flex app or even write some
> on
> > my own setting that option to ON - change the  way how things are
> > outputting after compilation ? Do you mean that:
> >
> > <Button id="myid" /> - Option is ON
> >
> > output will be:
> >
> > <Button localId="myid" />
> >
> > I'm sorry if I misunderstand you completely :)
> >
> > Thanks,
> > Piotr
> >
> > pt., 2 lis 2018 o 08:31 Greg Dove <greg.dove@gmail.com> napisał(a):
> >
> >> In collaboration with Carlos, I worked on a compiler fix for some issues
> >> identified with localId in the javascript output. I pushed that a short
> >> while ago. This fixes
> >> -binding into the localId (in my local test cases) and
> >> -some occasional issues with referencing the instance from within script
> >> blocks in release (minified) code.
> >> Or at least, it does so for the cases I have been testing. If anyone
> else
> >> sees remaining issues with this feature that need more attention, please
> >> let me know.
> >>
> >> Now on to the 'subject' :
> >> As part of 'getting familiar' with this I went back to read old threads
> >> about 'id v.s localId'.
> >> I *think* these [1] [2] were the main ones, but maybe I missed some
> other
> >> discussions.
> >>
> >> After reading these, I wondered if anyone had changed their views about
> the
> >> implementation as it is, after having used it for a while.
> >>
> >> It may be too late to change things, but here are my quick thoughts
> about
> >> this:
> >> -My understanding is that best practice is to avoid multiple identical
> ids
> >> in the browser, irrespective of whether the browser is forgiving of
> that or
> >> not. If so, it might be good to have at least an option to set the
> default
> >> implementation to support 'best practice' (DOM ids 'off' by default,
> 'on'
> >> explicitly, to avoid 'duplicate ids by accident'). Maybe some sort of
> >> import wizard for a legacy flex project could do something like this in
> an
> >> IDE by default though. But it could be a compiler config thing too
> perhaps.
> >>
> >> -I can't think of a scenario where I would want to set both id and
> localId
> >> at the same time or what doing so would mean. Either you want to set the
> >> DOM id or you don't, in which case missing id and defined localId is
> more
> >> like a boolean for not setting DOM id (the implementation is not, but
> to me
> >> it seems that it could -maybe should- be). Maybe I am missing something
> >> here.
> >>
> >> -'id' is the basis for code completion/intelligence in legacy IDEs.
> Using
> >> 'localId' means this does not work in the legacy IDEs and newer IDEs
> need
> >> to add custom support for it. Anything that keeps 'id' as the primary
> local
> >> identifier seems like the best way to get more life out of legacy IDEs.
> >>
> >> So to me, the simplest option seems to be more along the lines of
> >>
> >> <Instance id="myLocalOnlyId" localId="true" />
> >> <Instance id="myLegacyId" localId="false" />
> >>
> >> Semantically it is probably better as 'localIdOnly' for the boolean
> >> setting, but 'localId' is shorter (which is perhaps better).
> >>
> >> In this case, you get more mileage from older IDEs, and a simpler
> >> implementation for updating IDEs to handle the extra mxml-only boolean
> >> setting. In simple terms everything else works the same so the IDEs
> still
> >> work for code intelligence.
> >>
> >> An unspecified 'localId' boolean in mxml would currently be the same as
> >> false, but could possibly have a global configuration default - not sure
> >> about that, but maybe it could be useful.
> >>
> >> If there is an issue with styling on the swf side with valid multiple
> ids
> >> vs. html, then I think the swf side could perhaps be outlawed in favour
> of
> >> best practice for html. Too much? :)
> >>
> >> Anyhow, I am just raising this now in case anyone else has changed their
> >> thinking after using it as-is for a while, and before it gets too late
> to
> >> consider changing it (if it is not already too late).
> >> If there is some consensus to change this, I am happy to work on it.
> >>
> >>
> >>
> >> 1.
> >>
> >>
> http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i40.html#a63276
> >> 2.
> >>
> >>
> http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i60.html#a63919
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
>
>

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