Enhance Search: Search All Nodes (Incl. Collapsed) & Auto-Expand — True Filter, Not Just Highlight

[tearf001]

Is your feature request related to a problem? Please describe.

My understanding is that headless-tree's search currently acts more like highlighting within visible items rather than a true filter across the entire tree. It filters based on tree.getItems(), meaning nodes in collapsed folders are undiscoverable. This can be frustrating, as users might incorrectly assume an item doesn't exist when it's merely hidden.

Describe the solution you'd like

I would like the library to provide built-in support for a search mechanism that comprehensively scans all nodes (both visible and collapsed) and, upon finding matches, automatically expands the necessary parent paths to reveal these matches. This would align the search behavior more closely with a true "filtering" paradigm rather than just "highlighting."

This could be implemented as:

1. Comprehensive Node Scanning: Extend the existing search feature (or introduce a mode) to traverse the entire data source, regardless of the current expansion state of nodes.
2. Automatic Path Expansion: When matches are found within collapsed nodes, automatically expand all parent nodes in the path leading to the matched item(s), making them visible to the user.
3. Configuration Option: Introduce a configuration option, perhaps like searchMode: 'filter-all' | 'highlight-visible' or a boolean searchCollapsedNodes: boolean, to control this behavior. This would allow developers to choose the search paradigm that best suits their application. The default could remain the current behavior for backward compatibility.

Describe alternatives you've considered

Currently, achieving this comprehensive search behavior requires developers to implement custom solutions, which typically involve:

• Overriding the default getSearchMatchingItems method or implementing a custom search feature.
• Manually traversing the entire data source, potentially using methods like tree.retrieveChildrenIds() recursively.
• Managing the expansion state of parent paths using tree.applySubStateUpdate("expandedItems", ...).
• Potentially leveraging the plugin pattern for more complex integrations.

While these approaches are feasible, they demand significant boilerplate code, a deep understanding of the library's internal workings, and shift the burden of implementing a common and expected UX pattern onto the developer.

Additional context

This "search-and-reveal" or "filter-and-expand" functionality is a standard user experience pattern in most tree components. Users generally expect a search operation to be exhaustive, typically expand collapsed directories/folders to show search results contained within them.

The implementation could potentially leverage aspects of existing functionalities (like expandAll) but would need to be more selective, only expanding paths that directly lead to search matches.

Proposed API (Example)

const tree = useTree({
  // ... other config
  searchMode: 'filter-all', // 'filter-all' (searches all, expands) vs 'highlight-visible' (current default)
  features: [
    syncDataLoaderFeature,
    searchFeature, // Enhanced to support the new searchMode or searchCollapsedNodes
    // ... other features
  ],
});

This approach would ideally maintain backward compatibility while offering this enhanced, more intuitive search functionality as an opt-in feature or a configurable mode.

[robmerki]

I was just about to leave a comment similar to this, thank you for posting. This is an excellent library, would be ideal if this feature existed.

[lukasbach]

Thanks for the input! I've also thought about a feature like this. It would likely be a feature that will exist seperately to the current search feature, and they could exist alongside each other, with the existing search working as a quick-navigate, and the new one acting as an alternative deep-search. But there will potentially be some reworkings of some internal structures necessary, since at the moment HT only maintains references to tree items that are visibly rendered, not an exhaustive tree.

[tarochipzz]

I was going to leave a comment similar to this as well.

Since at the moment HT only maintains references to tree items that are visibly rendered, not an exhaustive tree

Curious how we're thinking this in the longer term. I'm facing a number of challenge with this,
Searching is one of them which I resolved by finding all related nodes manually and controlling HT's expanded item's state, so it would be amazing if this feature existed 🚀

This also relates to the checkbox feature request in a way, as we would want the checkbox selection on a collapsed folder to also affect its children (that are not visible).

[lukasbach]

My idea for a longer-term solution to this, is to allow HT features to manually add items to a list of observed tree items that they believe are important for them to work, and thus have more than the visibly rendered items maintained as item references. I also hope for that to be a solution of the checkbox feature on async trees with children propagation (canCheckFolders=false), which will not be supported in the initial checkboxes version, but hopefully in the future. And it could also help with the problem you described in the checkbox issue thread. But I'm also open for other ideas on this.

[nickBes]

Does anyone have a workaround for this feature until it’s officially supported?