Hrm, I think I should have explained this better.

Because elements are `upgraded` it means that an <x-foo> can be constructed
before it is registered as a custom element. At the exact moment `x-foo`
becomes registered, all instances of `x-foo` are magically upgraded to
their custom version.

Any `x-foo` constructed after `x-foo` is registered are born already
upgraded.

Now, because upgrade happens immediately upon registration, the order of
registration is important.

Say 'x-bar' uses 'x-foo'. It's very convenient for 'x-bar' to rely on all
'x-foo' being registered ahead of time. An application can ensure this by
executing the `x-foo` registration code before `x-bar`. Usually we ensure
this by simply having x-bar depend on x-foo, like so:

          <!-- make sure we define x-foo before registering x-bar -->

<link rel="import" href="../x-foo/x-foo.html">

<!-- register x-bar -->

<polymer-element name="x-bar" ...>
    ...
    <x-foo ...>...</x-foo>
    ...
</polymer-element>

This way we can be sure that x-foo.html is loaded before x-bar is
registered. If other elements import x-foo.html, de-duplication makes sure
that redundant imports are a safe no-op.

If we forget to do this and allow x-bar to be defined before x-foo, then
the x-foo inside of x-bar starts out life as a plain HTMLElement. Plain
HTMLElements only do attribute binding, so any bindings on x-foo created by
x-bar will only be attribute bindings.

If we make sure x-foo is loaded before x-bar, then when x-bar creates an
x-foo, the x-foo is all ready to go and has the necessary information to
create proper two-way object bindings.

HTH,
Scott


On Mon, Mar 24, 2014 at 3:03 PM, Scott Miles <[email protected]> wrote:

> This is a common problem if load your dependencies out of order.
>
> The module that defines the owner of `child-element` (not specified in
> your example) must import the code for 'child-element' or the binding can
> be misapplied.
>
>
>
> On Mon, Mar 24, 2014 at 2:56 PM, Junius Gunaratne <[email protected]>wrote:
>
>> Is there a proper way to pass JS objects to child elements? I'm trying to
>> pass a JS object to a child element as an attribute. This worked in Polymer
>> 0.2.0, but in 0.2.1 the object is changed to a string and I get
>> [Object][Object] as a string in the child element instead of the actual JS
>> object.
>>
>> <parent-element>
>>   <child-element flag="{{jsobject}}"></child-element>
>> </parent-element>
>>
>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Polymer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/polymer-dev/CAC57C_SxQ5jZJPTWws_Veam33DqK0LEX1juZJ4oUkW4tHZ3pOw%40mail.gmail.com<https://groups.google.com/d/msgid/polymer-dev/CAC57C_SxQ5jZJPTWws_Veam33DqK0LEX1juZJ4oUkW4tHZ3pOw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google Groups 
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/CAHbmOLZR9nEDi4Mnw-Egzj%2B-_c4o0oMAWLKH3S2k7hfDzHQoUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to