Tree widget: Incorrect category used for element visibility in filtered tree
There might be cases where incorrect category is used when determining or changing element visibility in filtered tree. For example ,if we have tree like:
Subject
|- Model
|- Category A
|- Element A
|- Element B (from Category B)
Filter path to Element B will be:
Subject -> Model -> Category A -> Element A -> Element B
At the moment when we try to determine/change visibility of Element B we go up in filter path and look for category. In this particular example we will find Category A and use it. However, Element B is in Category B and it should be used instead in all visibility operations.
Need a way to find real element category instead of the one that is shown in tree as an ancestor.
One of the easiest solutions to this would be to start showing categories for child elements. That way, we'd have the category node in filtering path and could use it for determining display status.
It would also remove the confusion described in this issue: https://github.com/iTwin/viewer-components-react/issues/1018.
@vermanas @jjbeckman13 @jason-crow, I'm interested in hearing your thoughts.
That approach seems reasonable to me
That approach seems reasonable to me
I think we could even show/hide the category based on whether it matches parent node's category - this would avoid making the hierarchy deeper in majority of cases, e.g. this situation:
- Category A
- Element A
- Category A
- Child element B
- Category A
- Child element C
When the categories match, we'd see this:
- Category A
- Element A
- Child element B (from Category A)
When the categories don't match, we'd see this:
- Category A
- Element A
- Category B
- Child element B
I could see a couple points of possible confusion, though:
-
When the parent/child hierarchy gets deeper, it may not be clear what the category is:
- Category A - Element A - Category B - Child element B - Child element C (category is "Category B" - is that clear?) -
When categories of some children match their parent, and some - don't:
- Category A - Element A - Category B - Child element B - Child element C (category is "Category A" - is that clear?)
A note regarding the proposed solution.
If we create the intermediate category node as an instance node, we'd have to way to control its visibility, as it would only have to affect elements under that specific node and not the others. A solution could be creating a Category navigation property grouping node and making it look like a category instance node.