feat: nested collection support

[nwidynski]

Closes #7277 (comment)

As discussed, this change focuses only on the bare minimum to get nested collections to work.

✅ 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:

🧢 Your Project:

[LFDanLu]

@nwidynski Heya, sorry about the delay, we were pretty busy with getting the release out. As mentioned in #7277 (comment) we are leaning towards supporting inputs in Gridlist first via something like #7360, which you had already noted doesn't solve the typeahead collision problem.

However, instead of making typeahead disable-able via a prop, we tossed around an idea of perhaps just doing some detection in the useTypeselect hook to see if the user was typing in an input and simply early return at that point. Any thoughts on that approach?

[nwidynski]

@LFDanLu No worries about the timeline 👍

I suppose you were exploring that idea to lighten the burden on the developer? If so, I don't see why these necessarily have to exclude each other. Preventing type select only when focus is currently on an input, will still cause issues with nested collections. Was there other reasoning for prohibiting the exposure of disallowTypeAhead?

As mentioned (see comment), this PR focuses only on the essentials of supporting nested collections and can be seen as independent of #7360. Only the Document key and type select are things we have to fix upstream to implement our use-case. Everything else we proposed, including #7360, we can temporarily implement ourselves through a custom virtualizer.

On that note, any feedback from the team on #7376?

[LFDanLu]

There was also a concern about exposing disallowTypeAhead since it may not be clear to a user when/when not to disable it. That being said, at a glance it doesn't appear in the grid spec so maybe not as core of an interaction pattern as previously thought. No feedback on #7376 just yet, I hope to take a look at it soon as soon as I get to a good place with the SearchableMenu/Autocomplete support myself.

[LFDanLu]

Just wanted to give you an update, but the team tested this today and things looked pretty good. Only thing that we noticed was some of the examples in the Table docs here broke, I'll see if I can get a chance to dig soon. Still seeing about getting another pair of eyes on this. The team is also juggling a couple of other PRs alongside this one with widespread changes (usePress refactor/shadowDOM support) and is a bit worried about stacking them all into a single release. Ideally we'd give them all some time to bake before shipping, will keep you posted.

[nwidynski]

@LFDanLu Thanks for keeping me posted. The regression you noticed actually comes from a bug in the docs, which was uncovered by the improvement to Table. I fixed the same issue in Table.test.js already, where columns were not forwarded to the underlying Row, but missed it in the docs. Good catch regardless 👍

react-spectrum/packages/react-aria-components/docs/Table.mdx

Line 388 in 262cc75

<Row id={id} {...otherProps}>

[snowystinger]

Hey, just wanted to let you know we haven't forgotten about this. We're just moving a bit slowly right now as a few team members are on vacation. Thank you for your patience.

[devongovett]

what happened here?

[nwidynski]

This addresses two issues. The first is #7655, which we scheduled as a follow-up to this PR but has since landed. Second is that drag & drop hooks generate their own id without a defaultId, overriding any custom ids here.

[devongovett]

hmm does the latter case still occur? I think mergeProps should merge the ids

[nwidynski]

You are right. @LFDanLu and I just agreed it would be better to hand the id down to gridlists call to useDroppableCollection to avoid implicitly relying on mergeProps #7379 (comment)

[nwidynski]

I will just push that as follow-up once i get into the office tomorrow 👍

[devongovett]

Hope you don't mind, I've pushed some changes to try to contain this within the selection package as much as possible so we don't need to handle this in each individual collection component. This way we generate a collection id in useSelectableCollection (attaching it to the actual Collection object via a WeakMap), and assign it to a data-collection attribute at the root and on each individual item. Then we can query for items using [data-collection="..."] to get all items in the collection, or [data-collection="..."][data-key="..."] to get a specific item.