Open michaldudak opened 1 year ago
Since useList
is going to use in Select
, Menu
, Autocomplete (In future)
. does it makes sense to add Infinite scroll
feature in useList
itself (as it's one of most requested feature)? Once it is implemented in useList
, Autocomplete
just need to pass necessary props to make it working.
I don't think components other than Autocomplete would make use of infinite scroll, so we need to be careful not to include features that won't be used but will increase the component size. I think we can add an event to the List fired when scroll is near the bottom.
@michaldudak Infinite scrolling inside a list is in fact a very common feature rather than not, I have it implemented on my own by using the Intersection Observer. So it make sense to also add it to the List as you mentioned.
I've opened an issue to organize the scope of Autocomplete for material-next: https://github.com/mui/material-ui/issues/39963
I think at a minimum we can convert to TS
@michaldudak Hey, I would like to work on the useAutocomplete hook and convert it to typescript, if that would be ok?
There's no point in doing this now. We plan to create the new Autocomplete/Combobox component in Base UI and use it in Material UI.
The
useAutocomplete
hook was created before Base UI existed and has code patterns different from the rest of the hooks in the library. Additionally, it does not use the lower-level building blocks from Base UI (likeuseList
) but implements its whole functionality by itself. Reusing the same building blocks as other components could help us reduce the overall bundle size and have feature parity with the Select (where applicable). There are a number of issues reported that could be solved by replacing the implementation.Areas of improvement:
useList
instead of reimplementing keyboard navigationget*Props
functionsfreeSolo
)Issues that could be solved along the way:
Since this will likely be a breaking change, we should leave the current version intact (but deprecate it and remove it in the future).