fwiw, this sounds reasonable to me, a few questions though... On Mon, Feb 3, 2014 at 3:11 PM, Rafael Weinstein <[email protected]> wrote:
> Hi all, > > If you don't care about design minutiae of databinding, you can stop > reading now. > > I've been thinking about the semantics of ref and assigning the > bindingDelegate and there are a few problems with our current behavior > > -Assigning a different binding delegate once a template has begun > producing instances affects only future (not present) instances, resulting, > potentially, in instances coexisting with different binding delegates. > > -Ref (as in <template ref>) is resolved every time an instance is > produced. This is potentially wasteful > > -There's no way to "clear" a template (remove all instances and stop it > from operating) > Is "clear" different from assigning `model = undefined`? Should it be called "clearModel" or something like that, to indicate that it isn't clearing the template content? > > Also, https://github.com/Polymer/TemplateBinding/issues/151 shows that > binding to ref dynamically is potentially useful. > > As such, I propose some semantic/API changes as well as a design invariant: > > Invariant: > > -At any given time a template should have instances which are more or less > "of the same mold" (e.g. produced from the same template.content and > bindingDelegate). > > Semantic/API changes: > > -template should have a clear() API, which removes all instances, > essentially resetting the template's internal state (clearing the model, > bindingDelegate, etc...). > Most (all?) templates in Polymer set the model using createInstance. Does "clear" change anything for that case? (Probably doesn't change anything, since createInstance doesn't support if/bind/repeat on the template it is called on and it doesn't have an associated TemplateIterator.) > -ref should be resolved once, the first time a template produces an > instance. > > -assigning to ref causes the template to remove its instances and > reproduce new ones using the newly referenced content (by extension binding > to ref this to be declarative). > Does assigning ref have a similar issue to bindingDelegate, where assigning it out-of-order causes something expensive to happen? I guess the difference is: we assume most of the time "ref" will be initialized from an attribute (either fixed value or via data binding), whereas bindingDelegate must be set programmatically. > -assigning to bindingDelegate once the template model is assigned throws > an Error. I realize this isn't very DOM-y, but the alternative which > ensures the invariant is to act like ref, removing all instances and > starting over. In the case of bindingDelegate, it's less clear there are > use cases which drive this and simple ordering mistakes (assigning the > bindingDelegate after the model) potentially create a very expensive no-op > which is easy not to notice. > Hmmm, since you can set bindingDelegate anytime before you end your microtask, I'm not sure it would happen much in practice. OTOH, I can't really think of a valid use case for changing the bindingDelegate after the fact, without just calling "clear". 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/CAJup4OX9_wWhs2caw8cJRcY1PEKS5vY6kOu1s4W1MemiUV-Txg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
