On Mon, Mar 10, 2014 at 5:04 AM, Addy Osmani <[email protected]> wrote:

>
>> 1) Merge the NodeBind Repo into TemplateBinding.
>>
>> This will basically mean just moving the source & tests from NodeBind
>> into TemplateBinding. This doesn't really change the design of the system
>> (at least yet), but it does acknowledge that these two things really go
>> together. It's one less repo to deal with and it means that we can
>> eventually write a single pseudo-spec for the whole system and have it be
>> in one place.
>>
>
> Thanks for explaining, Raf. So, last year MDV was was broken down into
> smaller efforts because some of the other primitives involved (<template>,
> Object.observe etc) were being pursued on their own. You mentioned that the
> last two - Node.bind() and TemplateBinding were considered sufficiently
> distinct to split them into their own primitives. Is the main reason for
> the merge that we feel it would be more plausible to get vendor buy-in to a
> single spec that contains both rather than the individual pieces?
>
> I share Igor's sentiments below that the two pieces seem useful enough on
> their own and would be interested in hearing more about the reasoning for
> not keeping them apart. I'm sure there's a good set of reasons :)
>

Basically it's just unnecessary abstraction that we're paying a on-going
maintenance cost for and there are presently no known customers for one or
the other separately.

Also, I just no longer believe that there's a credible path to
standardization for Node.bind separate from TemplateBinding. Putting them
in one repo means we can write a single pseudo-spec which lives with the
impl & describes the entire design and have a single reference point for
if/when another UA becomes interested in standardizing.


>
>
>>
>> 2) Remove Node.prototype.unbind, Node.prototype.unbindAll.
>>
>> It's somewhat less clear to me that nodes should ever be unbind-able
>> (rebind-able, or imperatively bind-able beyond template instancing, for
>> that matter). The only use-case we've encountered for doing this is
>> cleaning up (shutting down observation). However, if WeakRefs become
>> available in ES or if TemplateBinding/NodeBind get standardized (and
>> therefore make weak references available from c++), cleaning up observation
>> can be a concern of the node itself, and not require external interaction.
>>
>> Thus, the current design where Node.prototype.bind() is returning a
>> "close-able" object is really only internal API for the prollyfill.
>>
>> The main motivation for doing this is perf. Unbinding and setting up the
>> .bindings object during construction are significant work.
>>
>> I know that Polymer is currently using unbind and unbindAll(), but my
>> proposal is for polymer to do what TemplateBinding does, which is to keep
>> an array of closeable objects for each fragment that will eventually need
>> to be cleaned up, rather than traverse a fragment and unbind all nodes.
>>
>
> SGTM.
>
>
>>
>>
>>  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/06921a0e-491f-4acf-a6bc-591ffe5721c6%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/06921a0e-491f-4acf-a6bc-591ffe5721c6%40googlegroups.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/CABMdHiQ%2Baxg5mQoO8yaZpX60V2nHv-6mLnsaNh%2BJ5UCQQu8J1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to