can't make bindings to objects on elements instantiated by mdv

[morethanreal]

reduction: issues/pending/mdv-repeat-binding

I cannot make an attribute binding to an object on an element instantiated by mdv, ie.,

The obj properties of x-foo are the stringified objects, not the actual object.

[sjmiles]

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?

[morethanreal]

It doesn't get called for the repeated instances.

[sjmiles]

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 notifications@github.comwrote:

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
.

[morethanreal]

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

[sjmiles]

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 notifications@github.comwrote:

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
.

[morethanreal]

@rafaelw help?

[rafaelw]

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.

[sjmiles]

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.

[rafaelw]

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.

[sjmiles]

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?

[rafaelw]

Fixed in toolkitchen/mdv@c22bcf7