Material-ui: [Autocomplete] support pagination on Asynchronous requests

[vadimka123]

Would be very nice to add any ability for support pagination on Asynchronous requests
Many resources have limitations on requests and we can not get all results at once
Also reading everything page by page can lead to exceed limit of requests and it will be too slow

[oliviertassinari]

@vadimka123 I'm not sure to understand the use case. From my perspective, pagination should not be necessary. Either you request the data incrementally and add them to the list of options, then once the list is fully loaded, you enable the search. Or you really have too much data and you opt for an instant search like call API, for each keystroke. What do you think?

[vadimka123]

@oliviertassinari
It's can be million of options for AutoComplete

you can see example of this feature in select2 library
https://select2.org/data-sources/ajax#pagination

react-select has onMenuScrollToBottom callback and it's help to build bussiness logic for pagination in async requests

Even ordinary callback would really help

[oliviertassinari]

@vadimka123 Thanks for the link. Ok so if you have millions of options, you would need to perform a query per keystroke, similar to https://material-ui.com/components/autocomplete/#google-maps-place. What's your API like?

[vadimka123]

@oliviertassinari, various CRMs like Salesforce, Pardot, Eloqua, Marketo

Also I updated prev comment
Please, note

[oliviertassinari]

@vadimka123 Do you have an example of such API so we can have a look at how we can best handle it?

[vadimka123]

@oliviertassinari
Pardot, Eloqua and Marketo - have only paid instances
In Salesforce you can register free dev instance, you can read docs (https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_query.htm), but need a lot of work for API realization

[oliviertassinari]

@vadimka123 Ok, I see your point. You have an autocomplete like API that returns x results and you would like to allow users to scroll down the list of options instead of asking them to refine the query with something more specific that returns fewer results, below the pagination logic.

If it's accurate, I would challenge the use case for it in the first place. Forcing users to refind the query might yield a better UX. It might not be very important to support. However, we can explore it further. They are multiple elements to uncover here:

• The component exposes enough API surface to implement this but it would require extra work each time, for each developer.
• We would need to detect when we are about to reach the end of the scroll.
• We would probably want to add this in the public API, it's definitely required to explore paginated data, e.g. onScrollToBottom.
• We would need to display a loader when we reach the bottom of the listbox to indicate that more items are being loaded.
• The final step is the network request. There is a wide variety of possible endpoints people can query, from REST to GraphQL APIs.

[oliviertassinari]

So, if you provide a custom ListboxComponent component, you can detect the scroll-bottom with:

      onScroll: event => {
        const listboxNode = event.currentTarget;
        if (listboxNode.scrollTop + listboxNode.clientHeight === listboxNode.scrollHeight) {
          console.log('bottom');
        }
      },

[vadimka123]

@oliviertassinari
I think you should not override Material UI by business logic for this case
Business logic (like API requests) should make developer who uses your library
You should provide ability for make this business logic, also add very basic example would be great

Callback when menu is scrolled. At this point you offer one option to implement this. It's great
Also user can move to end of list of options by using key buttons. It's also should be handled
It's require more work for developer, but looks like it's possible now

---

Also there is one big catch
Already have a bad experience with this in react-select
Part of users can enter "End" key button and this automatically move user to last option (maybe exists other features for make this), ability to disableprevent this feature would really help

---

Per documentation you have loading state. It's can be used for add loading indicator as last option if exists other options?

[oliviertassinari]

@vadimka123 Yeah, I'm not opposed to a onScrollToBottom prop, but I would like to get more feedback that it's frequently needed. I suspect it's not.

---

Part of users can enter "End" key button and this automatically move user to last option (maybe exists other features for make this), ability to disableprevent this feature would really help

WAI-ARIA makes the Home and End key handling optional: https://www.w3.org/TR/wai-aria-practices/#combobox. Could you share more on what it can be problematic? I think that we can consider such an option.

---

Per documentation you have loading state. It's can be used for add loading indicator as last option if exists other options?

I don't know. I guess yes?

[vadimka123]

@oliviertassinari
If I use custom ListboxComponent I can't pass any props to this component

[oliviertassinari]

I have added the waiting for users upvotes tag. I'm closing the issue as we are not sure people are looking for such abstraction. So please upvote this issue if you are. We will prioritize our effort based on the number of upvotes.

[jedwards1211]

@oliviertassinari I'm not sure it's a great idea to only provide onScrollToBottom and just load more and more data. I think it would be better to include onScrollToTop if pagination is implemented. I guess it's not likely with an autocomplete that someone would keep scrolling until the browser runs out of memory, but I generally want to guarantee that any paginated view has bounded memory usage. A lot of infinite scroll examples I've seen, even in react-virtualized, aren't responsible about this.

[oliviertassinari]

I'm still confused about the problem we are trying to solve here. So far, I have seen the following mentions:

1. "A have millions of options".
   In such a case, you will need to run a query to the backend for every throttled keystroke. We can't expect the end-users to scroll on many options. After 10, I would start to question the human attention and focus capability. For instance, Google displays at most 10 searches autocomplete suggestions.
2. "My backend displays x records, use pagination for more".
   In such a case, I would recommend to first try to increase the number of records returned per page. I would expect 100 returned records on page 1 to be way more than enough.
   If it's not possible (I would be surprised), developers could eagerly load multiple pages.

In both cases, I believe the Autocomplete components don't need any changes. Is it accurate? What did I miss?

---

To summarize, we are waiting for a compelling reason. Why would an end-user or a UX designer would want to implement this behavior?

[jedwards1211]

Fair enough, yeah I guess it's not likely that the user would scroll a huge amount