iTwin
Option to have the items in the tree include a 'count'
Package @itwin/tree-widget-react
We would like an option to show a 'count' of the leaf nodes under a given node, like this:
- Do you need this in a specific tree, or all of the trees in the package?
- Do you need the count on all non-leaf nodes?
- Are you willing to sacrifice performance for this extra information?
- Just the classification tree
- We'd like it on all nodes that are classifications. At a certain point, we list the elements that are underneath each classification, and the children below those. We wouldn't need, for example, the number of child elements under an element. Just the amount of elements under a classification.
Example -- I have an iModel with 3 parking lots in it. Site Elements shows (3) [in blue in the image]. Parking Lots shows (3) [green]. There is one parking lot that points to Classification-1, so that gets (1). Two parking lots point to the Default classification, so that gets (2). That's as deep as we'd need the values to go -- as soon as we move away from classifications and into the elements themselves, we wouldn't need any more numbers. So, Layout Parking Area-4 wouldn't need a count of it's children or something, that'd be confusing.
The point would be to be able to tell at a glance -- "I have 3 site elements, and they're all parking lots. One is in Classification-1, and the rest are in Default"
- A bit, sure! Ideally it'd be an option that we could toggle off/on (in code) and we could play with it and decide if it's worth it
Ideally it'd be an option that we could toggle off/on (in code) and we could play with it and decide if it's worth it
This is a pretty significant piece of work. I'm not sure I want to invest my team's time if this is just to play around and see if you actually need it at all. Is the requirement backed by some user feedback?
In that case, I completely agree.
Do you have an estimate on how big the performance impact would be? Right now it's basically instantaneous to 1) open the tree and 2) open a node. I'd imagine that as long as both of these stay under a second, then it's completely fine.
If it'd be easier to expose a way for us to calculate the suffix of a given node ourselves, that could work as well. Maybe different applications would want different things shown? I can imagine we could write a custom query to solve our case, and maybe other applications with different data structures could do their own thing as needed.
It did come up in our first user call yesterday where we demonstrated our classification tree, and both of our PM's support it.
Do you have an estimate on how big the performance impact would be?
For smaller iModels this would likely be negligible. For larger ones - need to see. We have a couple of ideas how this could be implemented.
If it'd be easier to expose a way for us to calculate the suffix of a given node ourselves, that could work as well.
This would be preferred to us, too, as it opens possibilities for other use cases. I'm willing to have this on our backlog.
Based on your comments, am I right to assume that this is not of highest priority?