spectrum-web-components
spectrum-web-components copied to clipboard
[Feat]: sp-menu component to provide support for virtualizing sp-menu-item
Code of conduct
- [X] I agree to follow this project's code of conduct.
Impacted component(s)
sp-menu, sp-menu-item
Description of the requested feature
For a large menu list using the sp-menu
we would like to be able to virtualized the sp-menu-item
for performance gain. While this does partially work right out the box, there is a problem with tab navigation. Once the focus is set into the menu item, using the arrow key to navigate can only navigate to a subset of the list.
Here is an example: https://studio.webcomponents.dev/edit/oPXMxECYa2Hl67I0mEG4/src/index.ts?branch=swc-menu-virtualizer%40x6l1txiIKneNlFAZY2ShSrq382h2&p=stories
Mockups or screenshots
No response
Implementation notes or ideas
No response
Some off the cuff thought:
- have you tried this with the
virtualize
directive rather than a virtualiser element? - Likely this runs afoul of the connected/disconnected logic in
<sp-menu-item>
as it recycles DOM instead of removing it. There’s not a lot of “state” in a Menu Item, but would you expect to directly leveragevalue
here as a possible reactive hook to trigger updates, instead? - An
<sp-grid>
or<sp-table>
element would accept an array ofitems
directly, a similar API is proposed by<sp-combobox>
, how would you compare that approach to composing a virtualizer element as a child of the container? - Your demo show 100 items in the list. Have you done any tracing at which point you’d see a virtual list as being preferable to a static list?
- A virtualiser doesn’t inherently need to know about its entire list, but a menu would, particularly when converting of an accessibility API. Whether or not you render them all to the page, will you know the entirely of you Menu Items in order to fulfil requirements in this are?
- In either Table or Grid, I’d have to confirm, we take a render item as the insides of an item and then wrap that content with an item to ensure the accessibility contract, would you see that as practical for you in this case? Or would you prefer to take on accessibility responsibilities as well?
Excited to dig further into this convo!
The main reason that we're exploring this approach is from a performance analysis from Google Lighthouse, one of the area that gave us low score.
I have not explored the virtualize
directive yet, that was my next thing to explore. As for <sp-grid>
and <sp-table>
element I'm not sure if it it will our design.
One of the main reasons to use SWC is to get the accessibility features right out of the box, so we definitely want to avoid having to handle the accessibilities ourselves.
virtualize
directive yield with the same result as the virtualizer element:
https://studio.webcomponents.dev/edit/collection/P69Fy1cWB7KlLVvStVRK/5X38x8tuk5qh22qcPGri/src/index.ts?p=stories
Blocked by https://github.com/adobe/spectrum-web-components/issues/4101