TreeView usage

[janhassel]

I had to implement the TreeView component recently and ran into a few issues regarding the usage and wanted to discuss what of it is intentional and what are bugs. Also, can they be fixed or would they technically cause breaking changes?

1. No auto-rerender on state prop change

Updating props.active and props.selected on TreeView does not render automatically. A force re-render (for example through setting a key is needed to apply these changes.

Proposed action

This can probably be addressed by using the useControllableState hook, but would it technically be a breaking change since it modifies the behavior or is this considered the expected interaction and just bugged?

2. Unclear usage of props.active and props.selected on TreeNode

The usage of props.active and props.selected is unclear at first as they exist on both TreeView and TreeNode. Based on other Carbon components I was expected to set props.active = true on a given TreeNode before realizing these would be overwritten by the parent TreeView. Same for props.selected.

Proposed action

Can be handled by documentation

3. Misleading documentation around props.active and props.selected

I found it misleading to read the props.active prop definition:

Mark the active node in the tree, represented by its value

This suggests that whatever I pass as props.value would be used to set the state. In fact though, the TreeNode's id is used.

Proposed action

Either documentation update to reflect that the IDs are used or make the component respect props.value instead (technically a breaking change without further actions though).

4. Undocumented props.id on TreeNode

See 3. above. Each TreeNode is given a unique ID if none is passed via the props. These IDs are then used for props.selected and props.active. Support for props.id is undocumented though and can only be found by looking at the source code.

Proposed action

Goes hand in hand with point 3. Either expose props.id or use props.value as the internal id.

I could imagine that in order to avoid a breaking change, props.id could be deprecated (although never officially exposed) and if no props.id but a props.value is passed, to use props.value as the internal id. Alternatively the other way around (deprecating props.value and exposing props.id).

---

I'd be curious to hear which points you see as bugs that can be fixed, which ones are blocked and which ones are just based on wrong assumptions from my side.

[tay1orjones]

@emyarod I'm curious your thoughts on this as you established the bulk of the TreeView API. Are some of these intentional?