emberjs
changed each-behaviour for indexed arrays in 2.10
Hey!
I just noticed that Ember 2.10 introduces a changed behaviour when looping over indexed arrays with unset indexes.
Let's assume this array:
let a = [];
a[5] = 'foo';
a[6] = 'bar';
and this hbs:
{{#each testArray as |v k|}}{{k}},{{/each}}
In 2.9 this produces 5,6 and in 2.10 it produces 0,1,2,3,4,5,6.
I also made a twiddle for that
@Suven that seems like a bug. Perhaps the implementation has changed from using forEach to a for loop. (just a guess).
⚡ cat changed-each.js
a = [];
a[5] = 'foo';
a[6] = 'bar';
for (i = 0; i < a.length; i++) {
console.log(i, a[i]);
}
a.forEach(function(v, i) {
console.log(i, v);
});
⚡ node changed-each.js
0 undefined
1 undefined
2 undefined
3 undefined
4 undefined
5 'foo'
6 'bar'
5 'foo'
6 'bar'
Yup, that might be. I guess for-loops were tempting with perfomance having in mind first.
Just a little remark (although I guess that's obvious): This also happens when only the value is accessed (i.e each myArray as |val|)
I can confirm that it's bugged. Also using each-in instead of each temporary solves this problem.
The issue here is that (for performance reasons) we are using a standard for loop for {{#each support in 2.10+. Prior versions used .forEach and that natively support sparse arrays (and that is one of the reasons for some known performance issues).
We did it intend to support sparse arrays in prior versions and making changes to 2.10+ to support them would negatively impact performance of all usages of {{#each which is not an acceptable trade off for us.
We should document the fact that we do not support sparse arrays with {{#each in the API docs and add a test (likely a tweak of #14760) that shows the current behavior is intentional.
For folks that definitely need this support, I'd recommend using {{#each-in as someone else mentioned above.
@Suven I labelled this as "documentation" per @rwjblue comments above
For folks that definitely need this support, I'd recommend using {{#each-in as someone else mentioned above.
