Different behavior of {{@last}} when {{#each}} in {{#each}}

[zordius]

1. When {{#each}} on object, {{@last}} is undefined
2. When {{#each}} on array, {{@last}} will be true in last run
3. When {{#each}} inside another {{#each}} , {{@last}} will be set by outer {{#each}} and the behavior of 1 and 2 changed.

Sample code here:
http://jsfiddle.net/y4pd8qs2/1/

[kpdecker]

We don't know if a value is the last one in the object when doing for in iteration that is needed for object iteration. We don't want to do two scans to create a keys list and then iterate over that as that can be expensive but we might be able to defer the execution by one step and explicitly handle the last value outside of the loop.

[JosephClay]

@kpdecker What if we used Object.keys and then iterated over the keys? There would be a small performance hit, but it should be minor and allow {{@last}} to work consistently.

[kpdecker]

Object.keys is not supported by older versions of IE.
http://kangax.github.io/compat-table/es5/#Object.keys

[JosephClay]

It's easy to shim or use a basic fallback:

var keys = Object.keys || function(obj) {
    var arr = [];
    for (var key in obj) {
        arr.push(key);
    }
    return arr;
};

[zordius]

Ya, the idea is ......if we like to 'do not support {{@last}} on object' , it should be consist.
But , when we do {{#each}} inside {{#each}} , the inner {{@last}} seems to be copied from outer {{@last}} , and break the 'do not support {{@last}} on object' rule.

'to support' or 'not support' is not main issue. :)

[kpdecker]

The last value you are seeing on the inner iterator is coming from the context of the parent execution, since the data fields extend vs. create new sets of data.

[kpdecker]

Released in 3.0.0