Add search result auto-expansion and virtualization support for large trees

[Duck-98]

Is your feature request related to a problem? Please describe.
When searching and filtering tree data, nodes that match the search criteria are not visible if their parent nodes are collapsed. This creates a poor user experience as users cannot immediately see all search results and must manually expand multiple parent nodes to find the matching items.

For example, if I search for "item-3-2" which is nested under "folder-1/folder-2/folder-3", I cannot see the result unless all parent folders are already expanded.

Describe the solution you'd like
I would like to implement two key features:

1. Enhanced Search Functionality:

   • Automatically expand parent nodes when their children match search criteria
   • Highlight matched nodes for better visibility
   • Show breadcrumb path for deeply nested search results

2. Virtualization Support:

   • Implement virtual scrolling to handle large data sets efficiently
   • Only render visible nodes to improve performance
   • Maintain smooth scrolling even with expanded search results

Describe alternatives you've considered

1. Implementing a separate search results panel that shows matched items in a flat list
   • This would work but breaks the hierarchical context of the tree
2. Only showing matched nodes and their direct parents
   • This would be simpler but might lose important context from the tree structure

Additional context
This enhancement would significantly improve the usability of the tree component, especially for large data sets where users need to quickly find specific items in a deep hierarchy. The current implementation requires too many manual interactions to view search results.

For the virtualization feature, I plan to utilize the react-window library, which is well-maintained and provides excellent performance for handling large lists and grid layouts. This library would help us implement efficient virtual scrolling while maintaining smooth performance even with expanded trees containing many nodes.

I would greatly appreciate your feedback on this feature request. If you think this would be a valuable addition to the library, I would be happy to contribute to its implementation. Please let me know if you would like me to proceed with this enhancement and if you have any specific guidelines or considerations I should keep in mind while implementing these features.

[minop1205]

@Duck-98 Thank you for your comment!

For the search functionality, we prefer to provide a hook or helper rather than extending the functionality of the component.
We would like to leave the specific implementation to the users of this library, as there are many possible use cases for how to display the search results.
For example

const [filteredTree, openIds] = useTreeSearch(searchText);.

This takes a search string as an argument and returns the filtered tree and the IDs of the nodes that should be opened.

Regarding virtualization of the tree, I think it is difficult to virtualize the tree because all the nodes in the tree are not flat but nested, but I don't have a good idea for this. I would like to know if you have any solutions.
Tree virtualization is a feature that has been requested since the beginning of this library, so if it can be implemented without sacrificing functionality, it would be welcome.

[Duck-98]

@minop1205
Thank you for your thoughtful feedback on the tree virtualization and search functionality. I'd like to propose a detailed implementation approach that addresses both the performance concerns and maintains the library's flexibility:

Regarding virtualization

1. While I initially attempted to implement virtualization while preserving the nested tree structure, I found that flattening the tree structure provides a more efficient solution. However, I want to emphasize that:

   • The flattening transformation will only occur when virtualization is enabled
   • When virtualization is not needed, the tree will maintain its original nested structure
   • This approach ensures we don't impose unnecessary performance overhead on simpler use cases

2. For the technical implementation, I'm proposing to use @tanstack/react-virtual instead of react-window. The reasons for this choice are

   • Significantly smaller bundle size
   • Rich set of built-in hooks that provide more flexibility
   • Better maintenance and community support
   • More modern API design

3. The implementation will preserve all existing functionality, including

   • Drag and drop capabilities
   • Tree manipulation (expand/collapse)
   • All current event handlers and callbacks
   • Existing styling and customization options

4. Performance optimizations will include:

   • Rendering only visible nodes in the viewport
   • Efficient node expanding/collapsing
   • Smooth scrolling experience
   • Minimal re-renders

Regarding the search functionality:

1. As you suggested, I'll implement this as a separate hook (e.g., useTreeSearch) that:
   • Provides default search logic out of the box
   • Allows for custom search implementation through options
   • Returns both filtered results and expanded node IDs

Example search hook usage would look like:

const { filteredTree, expandedIds } = useTreeSearch(tree, searchQuery, {
 searchFn: (node, query) => // custom implementation,
// ...etc (yet)
});

Would this approach align with the library's goals? I can proceed with a proof-of-concept implementation if you think this direction makes sense.

I'm particularly interested in your thoughts on:

1. The choice of @tanstack/react-virtual over react-window
2. The conditional flattening approach based on virtualization being enabled
3. Any specific edge cases or scenarios you'd like me to consider in the implementation

[minop1205]

@Duck-98 Thank you!

As you said, it is difficult to apply virtualization to nested DOM trees.
Therefore, if virtualization is to be applied, the tree must be represented in a flat DOM structure.

However, recombining the tree into a flat DOM structure would be a very difficult modification, since it involves the basic implementation of this library.

The conditional flattening approach is one solution to this.
Alternatively, you could add a new component that supports virtualization as follows.

import { VirtualizedTree } from “@minop1205/react-dnd-treeview”;

If virtualization is almost always a separate process from the existing implementation, it may be easier to maintain the code by separating it into separate components as shown above.

One concern with flattening the DOM is how to determine and draw the dropable area as in the sample below.
I think we need to devise a way to cover such cases.

https://minop1205.github.io/react-dnd-treeview/?path=/docs/basic-examples-custom-drag-preview--custom-drag-preview-story

As for the library used for virtualization, I have no strong preference, but I think @tanstack/react-virtual is better than react-window because it is more actively maintained.

As for search, I think the implementation you suggested is fine. I think it is a good idea to be able to pass a custom search function as an option.

I am currently working on an update to this package and will release the next version in about two weeks.
This update will include

• Updates to various dependent packages.
• Adoption of flat config for eslint
• eslint rules review and code formatting
• Some additional features.

This version has extensive code fixes, so it is better to use this version as the basis for developing new features.