fix: Speed up tree collection builder flattening when expanding keys

[snowystinger]

Closes #8725

Note, this does not address initial load/render of Tree, this is just for expanded keys

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

visitNode in Tree for the expand all action takes
Before: ~20772ms
After: ~190ms

🧢 Your Project:

[rspbot]

Build successful! 🎉

• View the storybook
• View the S2 storybook
• View the documentation
• View the S2 docs

[snowystinger]

Best way to test this is to the root level visitNode in timing, I didn't include it so that the tests would all pass and we'd get a build, the delay/difference should be noticeable in the build, but just if you want numbers to put to it.

  let startTime = Date.now();
  for (let node of collection) {
    visitNode(node);
  }
  let endTime = Date.now();
  console.log(`Time taken: ${endTime - startTime}ms`);

[rspbot]

Build successful! 🎉

• View the storybook
• View the S2 storybook
• View the documentation
• View the S2 docs

[devongovett]

btw I was thinking a while ago that it might be possible to do the flattening incrementally instead of copying the whole collection up front. Basically you'd do it on demand in getKeyAfter / getKeyBefore etc. by traversing down the tree. BaseCollection already kinda does this for sections. TreeCollection could be implemented in a similar way but for items. We'd need to handle the special cases that flattenTree has currently for loaders/content nodes though.

[snowystinger]

@devongovett

Sure, but this is still a huge savings in the meantime and wouldn't preclude us from making those changes

[devongovett]

Oh I didn't mean now!

[reidbarber]

Awesome!