Fix re-ordering issues with Ember each #552
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#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
foo
and call the othersothers
.foo
is a single field.others
contain multiple fields. The way the view is laid out makesothers
use akey
that represents the index while thefoo
field uses akey
that matches the content. One is anumber
and the other is astring
.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 and0
is used. This breaks theeach
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 thekeys
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