The scenario that resulted in this weird behavior is when a condition involves a view layout where you have one field alongside other fields. Lets call the one field foo and call the others others. foo is a single field. others contain multiple fields. The way the view is laid out makes others use a key that represents the index while the foo field uses a key that matches the content. One is a number and the other is a string.
When conditions are involved, it'll toggle which field is displayed and the resulting keys being used change to match the new layout. We often end up with a scenario where there is a type mismatch with adjacent cells and 0 is used. This breaks the each functionality and instead of Ember re-ordering the DOM to match the rendered order of the component, it craps out and just appends it to the end. The fix involved forcing the keys to always be strings.
I would love to add tests for this but just testing this by hand was cumbersome so I'll leave it out for this PR.
CHANGELOG
Fixed condition re-ordering issue with Ember each in Ember 2.12 behaving weirdly with each when the comparison for keys involve type mismatches.
PATCH
The scenario that resulted in this weird behavior is when a condition involves a view layout where you have one field alongside other fields. Lets call the one field
fooand call the othersothers.foois a single field.otherscontain multiple fields. The way the view is laid out makesothersuse akeythat represents the index while thefoofield uses akeythat matches the content. One is anumberand the other is astring.When conditions are involved, it'll toggle which field is displayed and the resulting
keysbeing used change to match the new layout. We often end up with a scenario where there is a type mismatch with adjacent cells and0is used. This breaks theeachfunctionality and instead of Ember re-ordering the DOM to match the rendered order of the component, it craps out and just appends it to the end. The fix involved forcing thekeysto always be strings.I would love to add tests for this but just testing this by hand was cumbersome so I'll leave it out for this PR.
CHANGELOG