Passing JS objects between elements as attributes

[Junius Gunaratne]

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>

[Scott Miles]

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.

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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAC57C_SxQ5jZJPTWws_Veam33DqK0LEX1juZJ4oUkW4tHZ3pOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Miles]

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

[aakar...@gmail.com]

Hey Junius, 

I faced a similar issue, but if it is a work-around you need, then inside the "ready" method of Polymer, I tried parsing the string (in this case "jsobject") as JSON with JSON.parse() , and it worked. Not saying this is the best way to do it though. 

Aakar

[Aakar Desai]

Also, thinking more about your issue proper, it seems the problem is the interpretation of your Object per se. 

What your child element probably needs to know is the string representation of the JSON object so it can deduce it inside using the JSON.parse() method I stated earlier.

For that, you could do the following where you are declaring your actual element:

• Your flag attribute needs to be set via Javacript. A typical jQuery way would be:
   
   var flagVariable = JSON.stringify(jsobject);
   $("child-element").attr("flag", flagVariable);
  
  
• Once this is done, within the Polymer declaration of child-element, you would be getting the attribute "flag" as a string now. There, you could simply parse that string as JSON.parse(flag) //

This might just work. The reasoning is that string is a streamlined type used here to pass information, and then interpret it in its correct JSON format where required. Would love to hear back if this worked [ or was completely irrelevant - then we could probably dig deeper! :) ]