Search unreliable, causes 100% CPU and memory 1 GB+

[hyperknot]

I have 5000 nodes in a tree. Only 2 level, with about 5 "directories" and the rest being "files".

I'm using search by index, using such a simple function:

export function searchById({ node, path, treeIndex, searchQuery }) {
  return node.id === searchQuery
}

React Sortable Tree is very unreliable on such data.

1. It works 80% of the time, but it doesn't work on 20% of the time.
2. By force-swapping the searchFocusOffset to null and 0 again it works, especially if I put it in a setTimeout
3. Sometimes this causes 100% CPU use which doesn't stop as well as 1.2 GB of memory usage for the tab in Chrome's Task Manager.

My implementation is like this:

searchMethod={searchById}
searchQuery={searchQuery}
searchFinishCallback={matches => {
  if (matches.length !== 1) return
  window.setTimeout(() => {
    mapUIStore.setSearchFocusOffset(null)
    mapUIStore.setSearchFocusOffset(0)
  }, 0)
}}

Note: I'm using my own handling of collapsing / expanding "folder" nodes, with a dummyonChange={() => {}}, that's why I probably need the setTimeout.

Still the CPU and memory usage shouldn't happen.

// Because of this, I'm migrating my app to react-sortable-hoc, so I actually don't need this to be solved, I just wanted to report it.

[wuweiweiwu]

hi @hyperknot Thanks for bringing this to my attention. react-sortable-tree currently uses DFS (w recursion) for traversing the tree which in some cases, can be extremely un-performant.

Its on my todo list to implement a better search. perhaps BFS.

[orlowang]

@wuweiweiwu
add just-show-matched-node feature for new(maybe?) search, In my case, there is more than 10000 leaf in the tree, and search is common function, for now, I just re-render the tree with new matched data.

[wuweiweiwu]

@OWCC there is a prop for that! onlyExpandSearchedNodes

[cormacrelf]

You could also build a Lunr.js index and { work backwards from the results | cache paths in the index }.