On 5/20/17, 3:17 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi,
>
>If you make a component with something with an id in it and then use that
>multiple times in the same view (which is common pattern comping from the
>Flex world) are you going to run into this issue?
AIUI, it depends on if any code cares (expects one and only one component
with an id).
So the proposal is to support a new property called "mxmlID" that can be
used to find objects in an MXML document but does not set the
HTMLElement's id property. IMO, the proposal needs more discussion.
In more detail, for the following file:
---- Foo.mxml ----
<SomeBaseClass>
<SomeClass id="bar" />
</SomeBaseClass>
The compiler creates a property in Foo called "bar". Then in ActionScript
you can write "bar.someProperty". It worked this way in regular Flex as
well, and pretty much eliminated any need for a "getElementByID" API.
In the JS output for FlexJS, the HTMLElement "id" is also set to "bar.
This enables ID selectors in CSS. But you are not supposed to have more
than one HTMLElement with the same id. Although my understanding is that
the browsers will not care, but library code like in MDL might.
So, if someone does:
---- Baz.mxml ----
<SomeBaseClass>
<Foo />
<Foo />
</SomeBaseClass>
There still isn't a getElementByID call in FlexJS, so everyone writing
"bar.someProperty" is just fine. But underneath, the browser now sees two
HTMLElements with id == "bar" and third-party JS library code calling
document.getElementByID is going to get the first instance and can't get
to the second one.
The proposal is for someone to write instead:
---- Foo.mxml ----
<SomeBaseClass>
<SomeClass mxmlID="bar" />
</SomeBaseClass>
The compiler will still create a property in Foo called "bar" and in AS
you can still write "bar.someProperty". I'm trying to think of what else
will be impacted by allowing this.
Thoughts?
-Alex
