[base-ui][Autocomplete] Virtualization/infinite scroll support

[marcpachecog]

Summary 💡

Dashboard apps often handle extensive data, requiring efficient data management tools. The Autocomplete component is crucial for handling large data sets but lacks optimal performance when dealing with hundreds of records that need pagination.

Solution

Integrate virtualization and infinite scroll features into the MUI Libraries' Autocomplete component.

Benefits

• Efficiency: Virtualization renders only visible data, ensuring smooth performance even with extensive datasets.
• Seamless Navigation: Infinite scroll enable users to smoothly explore records without manual clicks.
• Time Savings: Users can access and review vast datasets quickly.

Examples 🌈

• https://mui.com/material-ui/react-autocomplete/#virtualization

Motivation 🔦

No response

[marcpachecog]

Hey @oliviertassinari and @michaldudak, Interested on what are your take about this.

[mj12albert]

A PR is underway ~ https://github.com/mui/material-ui/pull/35653

[brijeshb42]

@ZeeshanTamboli Assigning to you since you already have a PR.

[ZeeshanTamboli]

It's @sai6855 who worked on it.

[marcpachecog]

Thanks to all! So a PR about infinite loading is underway, great! But what about virtualization? The current proposed solution in the docs is somewhat boilerplate to implement, there should be some other way to achieve the same functionality. For example Antd has it built-in, even MUI DataGrid Pro has it and you can disable if it the case.

[oliviertassinari]

The current proposed solution in the docs is somewhat boilerplate to implement

If we change the demo to be one that can be easily copy and pasted, would it fix the issue? https://mui.com/material-ui/react-autocomplete/#virtualization.

One important constraint is that virtualization is not a so frequent use case, to be verified with the GA events, but only looking at https://github.com/bvaughn/react-virtualized-select feels enough to make this claim. So if we ever make a built in virtualization support, it must be tree-shakable.

[Nic-S]

I honestly believe that it is instead a common use case to have virtualisation.

[michaldudak]

Some believe it is; some believe it's not, which proves it's best to have it optional.

[marcpachecog]

@oliviertassinari @michaldudak If it is not built-in, a more compact solution I think it could provide a better DX and more adoption of this feature overall.

[Nic-S]

@marcpachecog having it built-in, with the ability to disable it (like datagrid) would be optimal for dx. if that is not possible, I agree with you, that a more compact solution could increase dx.

[marcpachecog]

Other libraries like headlessui are going towards this direction: https://github.com/tailwindlabs/headlessui/pull/2740