Large Trees

Why this works without a windowing dependency

TreeKit's internal architecture always computes a flat array of currently-visible rows (respecting expansion and any active search filter) before rendering — getVisibleEntries, run once per render via useMemo. This flat list is exactly the shape a virtualization layer needs: a stable, indexable array where item i is always at a known scroll offset (i × rowHeight). Turning on virtualized slices that array to the range currently in view and absolutely-positions each row — no separate library, no re-architecture.

O(n) selection, not O(n) per click

Indeterminate/checked state for the whole tree is computed in a single linear pass (see Indeterminate State), memoized on (data, checkedIds, selectionPropagation) identity. Checking one node doesn't re-walk the tree once per ancestor — it's one pass regardless of tree depth or checked-set size.

Structural sharing for async loading

When children load lazily (Async Loading), TreeKit merges them into an internal copy of the tree while preserving object identity for every untouched branch — loading one folder's contents doesn't invalidate memoization for sibling folders.

For most apps — hundreds to low thousands of visible nodes — you likely don't need virtualized at all; TreeKit's default rendering is already efficient enough. Reach for it once you're rendering tens of thousands of rows at once.