Add {{#unbound}} block helper #444

tomdale opened this Issue Jan 26, 2012 · 10 comments


None yet
6 participants

tomdale commented Jan 26, 2012

@ebryn and @wycats have been having some discussions about overall improvements to the view layer to make it easier to have large "unbound" or quasi-bound sections. There are a few open possibilities:

  1. #unbound blocks that would render initially and never update
  2. #group blocks that would render initially and re-render entirely if any child property changes. These blocks may not be exposed, but might be used internally as heuristics would justify (i.e. we'd try to determine whether individual updating was better than group updating, and choose the right answer). It might also be exposed.
  3. An optimization that would group several simple properties ({{foo}} {{bar}} {{baz}} would become a single grouped property, updated as needed). This would definitely be implemented as an optimization, probably at compile-time, and would not be exposed.

We are planning on meeting next week to hash out a basic plan, which we will then post here.


krisselden commented Jan 27, 2012

Does this include buffering large collection changes?

Updating a rendered collection view with a list schedules each item for insertion into the dom and is slow compared to rerender.

We had a rendered empty collection view that got the result of an ajax call and was slow to render on the phone. We switched to not rendering the collection view until the ajax call came back. That sort of spoils the whole data binding magic.


ebryn commented Jan 27, 2012

@kselden I created a separate issue for that optimization: #450

etabard commented Mar 21, 2012

Anything new on the unbound blocks ?

I have a collection of ~20 items and each item has a "sub" collection of ~20 items. It takes about 7seconds to render it. According to the profiler, bindings are really costly. And my content is static.

Do you guys have a quick workaround ? Also with the "binding helper" {{view XXX myVarBinding="somestuff"}}, is there a way to have a oneWay binding ?



ebryn commented Mar 21, 2012

@etabard We're working on improving collection performance. Have you tried using a build off master?

etabard commented Mar 21, 2012

@ebryn I tried using the latest "version" based on master. Here is a quick and really simple example of my use :
With firebug you'll have a full profiling.

It takes 1sec on my MB pro. With extra views and binding, it takes over 6secs.

This is blocker in my case. I'm releasing in two weeks and I'm out of ideas for improving performance here.

I also tweaked this parameter : ENV.USE_ACCESSORS = true;
It helps a little, but I don't know the side effects.


ebryn commented Mar 21, 2012

@etabard Did you notice improved performance in your app with ember-latest? You can use the unbound helper with property output to also improve performance. For example:

etabard commented Mar 21, 2012

@ebryn 20% faster with latest :-)
Yeah I forgot the unbound helper in my test case... I'll update my jsfiddle to reproduce my real test case !

I'm trying to unbind items inside an  {{#each}} block.
{{#unbound each items}} item {{/unbound}} doesn't seem to work.


wagenet commented Jun 6, 2012

@tdskate You can't chain Handlebars helpers. unbound only works for single properties right now. This issue is about providing a way to do something like what you're trying to do, which is why you can't do it.


wagenet commented Oct 20, 2012

Closing since we have a PR for this now.

@wagenet wagenet closed this Oct 20, 2012

@sbounmy sbounmy referenced this issue in DockYard/ember-easy-form Oct 17, 2014


Ensure that block form inputs use the correct for. #93

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment