grapoza
commented
1 year ago I'll have to take a look at this and see if there's a good way to wrap these up; right now it's every node for itself, so some reswizzling would have to occur (possibly with tree-level selection tracking, etc). It's a good idea, though. Maybe I could even introduce new events specific to something being selected or deselected (instead of just the state change), and have the selected event behave the way that's describe here? It may be too many events for selection, though. It's probably something best thought about after sleeping on it.
It probably doesn't directly help your scenario, but I wonder what the behavior of the getSelected method is if called from a treeNodeSelectedChange handler? I'd worry about race conditions or that kind of weird issue.
Just out of curiosity, would you be able to use an array of selected nodes to track them instead of an entire shadow tree? I'm always interesting in hearing about people's use cases.
luckyrat
Is your feature request related to a problem? Please describe. I'd like to track when the selected node is changed. Although the current API helps somewhat, it doesn't allow me to differentiate between a new node being selected and all nodes being unselected by the user.
It appears that sometimes/always the "unselected" node is sent to the treeNodeSelectedChange callback before the newly selected node.
Describe the solution you'd like Either reliably send all deselection callbacks before selection ones, or change the API so that it has two optional parameters (oldNode, newNode). Ideally that would be sent just once for a selection change in single mode.
For single-selection mode, this change would mean that a single variable in my parent component could track the selection status, whereas with the current API, I would have to duplicate the entire tree and track the selection status of each node, allowing for the brief period in which more than one node can be selected.