Fix column identification after filtering #506
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Domino987
approved these changes
Mar 12, 2022
This was referenced Oct 4, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Related Issue
#505
Description
The
changeFilterValuemethod of the data manager is incorrectly using thecolumnIdas an index. Generally this does not cause an issue, even though conceptually they are different values, because thecolumnIds are initialized from the indexesHowever if a column is drag and dropped to a different position, then the
columnIds and the column indexes are no longer guaranteed to match. To resolve this issue, took the logic for identifying a column fromchangeGroupOrder, which correctly handles thecolumnId.Impacted Areas in Application
Additional Notes
Looked through the data-manager, the only other instance I've found where we use the column id as an index is in
setColumns, when we look for theprevColumn. Theoretically this could break as well, if the same list of columns, but reordered, is passed to<MaterialTable />, but not quite sure how we'd fix it, without giving up looking for theprevColumnaltogether.