Component filtering breaks owners tree and list views
bvaughn opened this issue · 3 comments
- Owners tree
Entering the owners tree view can cause runtime errors (in reduceOwnersState
) if any owners have been filtered out of the tree. We need to guard against this.
- 17516b7: "Rendered by" list
It's a bad UX to click on an owner (in the right hand panel) if the owner has been filtered in the tree. Nothing breaks, but the selection just kind of goes blank. The owner probably shouldn't be clickable in that case.
Regarding the owners tree view, I think we have two options here:
- Bail out on showing the owners list breadcrumbs if we run into an owner element not in the
Store
. (If the backend filtered it out, then the frontend can't crawl past it.) This would be easy to implement, but isn't a very satisfying solution.- Show the owners tree but don't show any owners list breadcrumbs.
- Don't show the owners tree at all. (Just don't let it be opened for nodes that would be orphaned due to filtering.)
- Add a (async) renderer interface method to return the owners id list (with filtering taken into consideration).
- Return the filtered list of owners. This would be easiest, but might also be confusing since it filtering the owners doesn't make as much sense as filtering the full tree view.
- Return a list of owner objects (id, display name, key) and let the front-end display the filtered nodes differently to indicate that they exist, but they've been hidden from the frontend.
I think the last option (2b) is best.
Option 2b is a little trickier than I thought, because the owners list is currently constructed and managed by the TreeContext
since it's so tied into the rest of the tree state. This means we can't use suspense to power it. We could move it out into a separate, suspense-driven context that's derived from the tree context though I think, if we added ownerID: number | null
to the TreeContext
and removed the ownerStack
and ownerStackIndex
out into their own context.