Repository navigation
feat(tree): add trackBy to tree controls to keep the expansion of rebuilt nodes (#DS-5785) - #2253
Open
nazirgitwork wants to merge 4 commits into
Open
nazirgitwork wants to merge 4 commits into
nazirgitwork wants to merge 4 commits into
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
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.
Summary
A tree control tracks expansion by node identity, so with
KbqTreeFlatDataSource(or any source that rebuilds its node objects when the data changes) every expanded node comes back collapsed after a data update, and every row is re-created.FlatTreeControlandNestedTreeControlnow accept an optionaltrackByin a new lastoptionsargument. With it,expansionModelholds the node keys instead of the nodes, so expansion survives a rebuild. The tree also falls back to the control'strackByto re-use row views when its owntrackByinput is not set. Without the option, behaviour is unchanged: the key typeKdefaults to the node type.List of notable changes:
trackByand theKbqTreeControlOptions<T, K>options argument toFlatTreeControlandNestedTreeControl. Expand, collapse,expandAll, filtering, and state saving/restoring go through the key.K = TtoTreeControl,BaseTreeControl,KbqTreeFlatDataSource,KbqTreeSelectionand its event classes, andKbqTreeSelect, so a typed query or event can name the key type (KbqTreeSelection<Node, string>).KbqTreeBase: itstrackByinput now defaults to the control'strackBy, and the bound on the control type leaves outexpansionModel, so controls with any key type are accepted.FlatTreeControl.getDescendantsandgetParentsfor a node rebuilt since the last data update: withtrackByit is found by its key.kbqTreeNodeTogglehas no[node]binding: it now reads the same nodetoggle()acts on.kbq-tree-selectionafter re-used rows change order: the rendered options are re-sorted when only their order changed.trackByand how it relates to the tree's owntrackByinput.What should reviewers focus on?
expansionModelbecomesSelectionModel<K>.Kdefaults toT, so existing code compiles unchanged, as the unchanged API reports of the other entry points show. Thefilter-barreport changes only because the defaultedKis now written out.KbqTreeBase<T, C extends Omit<TreeControl<T>, 'expansionModel'>>:SelectionModel<K>makes a control invariant inK, so keepingexpansionModelin the bound would reject controls with atrackBy.trackBy(tree-base.ts): keys can't be turned back into values, so the saved state is collected from the currentdataNodes.renderedOptionsOutOfOrder()intree-selection.component.ts: the options query doesn't emit when re-used rows only move.