can't make bindings to objects on elements instantiated by mdv about polymer HOT 11 CLOSED

Run your example and put a breakpoint in toolkit/src/register.js on base.bind (~line 101). Does this method get called for the repeated instances?

I'm guessing it does, but then does not pass the 'inModel.isToolkitElement" test. Can you confirm?

from polymer.

It doesn't get called for the repeated instances.

from polymer.

Ok, in that case I suppose the problem is that the instances are not
upgraded in time to have the 'bind' method on them.

After they are stamped, look at the nodes, are they upgraded at all? I
assume they are.

If so, if you don't mind, put a breakpoint in watchDOM in CustomElements.js
and see if they are being upgraded by that method after stamping.

On Mon, Apr 1, 2013 at 12:43 PM, Yvonne Yip [email protected]:

It doesn't get called for the repeated instances.

—
Reply to this email directly or view it on GitHubhttps://github.com/toolkitchen/toolkit/issues/81#issuecomment-15733038
.

from polymer.

The nodes are upgraded by watchDOM. Seems like the problem might be by the time watchDOM runs, the objects are already bound by mdv?

from polymer.

Yes, that's the (first) problem. The nodes require upgrading before
binding. We probably have to seek help from the MDV guys on this one.

On Mon, Apr 1, 2013 at 12:52 PM, Yvonne Yip [email protected]:

The nodes are upgraded by watchDOM. Seems like the problem might be by the
time watchDOM runs, the objects are already bound by mdv?

—
Reply to this email directly or view it on GitHubhttps://github.com/toolkitchen/toolkit/issues/81#issuecomment-15733495
.

from polymer.

@rafaelw help?

from polymer.

Sorry for the delay. I'm still thinking about this one. It's a tough problem and it's kind of tied in with the lifetime and upgrading of custom elements.

In the abstract, I think there are two approaches to this:

1. Custom elements are upgraded while inside of template contents. When bind() gets called, the element is ready for it. No one seems to think this is a good idea, but I claim it's the most inline with allowing platform objects to be implemented in script. Built-in elements are fully alive inside of template contents and the expectation is that they know how to not to have side-effects while they are there. The real trouble here is (as Adam K says) we don't really trust script enough to let it fully implement platform objects.

2. Call bind() on elements later. At the moment, this is the only way forward. This has two variants I can think of:

2a) Call bind() on elements once they are insert into the document. The downside here is that it requires first removing the attributes which contain mustaches and worse it means that live DOM may attempt to act (fetch resources, run scripts, etc...) on an element which isn't really fully constructed.

2b) Expose imperative API on Node which allows the current bindings to be reflected. Template would call bind() while the element was in inert document, and when the custom element wakes up, it must inspect its bindings for any it wishes to override. I can't think of a concrete problem with this, other than it feels gross.

Opinions very welcome.

from polymer.

I'm confused about "1) Custom elements are upgraded while inside of template contents. When bind() gets called, the element is ready for it."

Is the idea that whatever 'bind' does is cloned and bind is never called on copied instances?

I don't have a good handle on what happens when cloning custom elements. A cloned custom instance must experience a fresh lifecycle, and I don't know what happens to the object state.

from polymer.

I'm also curious about what happens to cloned custom elements. However, that I don't think that impacts this issue. Here are the steps for MDV creating an instance

1. Clone the .content (the clone is still owned by the template contents owner (innert) document)
2. Call bind() on all nodes which have mustaches inline in attributes or text content
3. Insert the instance into the document (this is where adoption occurs)

Custom elements being upgraded while inside template contents helps because the elements would be ready to override bind() in step 2.

from polymer.

Ok, thanks for that explanation.

2. Call bind() on elements later. At the moment, this is the only way forward.

I'm not sure this is true. For polyfill, we only need a hook where we can call our element upgrade code. If you supply that hook between steps 1 and 2, polyfill is happy and we can simulate your preferred modus operandi. Did I forget something?

from polymer.

Fixed in toolkitchen/mdv@c22bcf7

from polymer.