To support infinite-scroll pagination style for Pagination component.

[alcarasj]

Problem

For example, a GET API response returns a list of data. However, the actual total amount of rows is unknown. Instead, the API response returns a token for the next page, which is subsequently used in a second request to retrieve the next page. In Cloudant, this is known as bookmark-style pagination (see https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-pagination-and-bookmarks). For all intents and purposes, let's call this infinite scroll pagination style. I don't think Carbon supports this style of pagination yet.

I think Carbon needs to support this form of pagination because it is a valid API pagination pattern used by teams in the industry. There is already an existing pagesUnknown prop for this component, but it still shows the page number selector dropdown when it is set to true. Also, there is no way to dynamically disable the next and previous page buttons on their own to reflect the said pagination style.

Proposed solution

To support the above pagination pattern I think this will entail the following extensions to the Pagination component:

• When pagesUnknown is set to true, then we should hide the page number selector dropdown because we can't jump from page 1 to page 4. This is because the actual total amount of rows is unknown.
• We should add boolean props like hasNextPage and hasPrevPage to allow the developer to dynamically disable the next and previous buttons.

[aagonzales]

@alcarasj do you have any visual specs or a code sandbox to show how this works?

General impression:
I can see a need for an infinite-scroll option. I don't think its necessarily interchangeable with other type of pagination. I think it would be reserved for a specific type of content and scenario. This NNG article has some good insights in this topic. I think my only concerns about it would be when we recommend using vs not using it.

Some questions for thought:

• Is this meant for data tables? Or what kind of content?
• Is this about pagination or more about lazy loading all content?
• How is this different than if a user selected a "show all" option?
• Could you still use the traditional pagination with pagesUnknown?

[aagonzales]

This is the conclusion statement from the NNG article about Infinite Scrolling. Some good things to keep in mind.

Conclusion: Infinite scrolling may seem like an elegant replacement for pagination. However, it’s not the answer for most websites. Infinite scrolling is probably not for you if site visitors want to achieve goal-oriented activities, such as when they need to backtrack or find specific information quickly.

[alcarasj]

@aagonzales

Thanks for the reply! It appears that the proposed pattern of behaviour is already achievable in latest Carbon. Please see sandbox here: https://codesandbox.io/s/carbon-components-react-forked-ixgbq . Note in the MOCK_DATA constant I'm roughly mocking what the UI would receive if the API returns a list of data in the infinite-scroll pattern (existence of previous and next page token). Then I just hid the page number selector dropdown, which is probably the only thing that needs to be changed?

Is this meant for data tables? Or what kind of content?

Yes, this is meant for data tables. The infinite-style scrolling pagination (in the context of Cloudant) is used for index performance.

Is this about pagination or more about lazy loading all content?

Both - this concerns the pagination of lazily-loaded content, i.e. in the infinite scroll pattern that is described, the API is only returning a subset of data with no indicator as to how much total elements are left in the entire set of data.

How is this different than if a user selected a "show all" option?

I think if the user selected "show all" then there would not be pagination? The user would just scroll endlessly without changing pages. However for the pattern described here, we are still paginating the data and allowing the user to switch between pages. It's just that we don't know how exactly how much data is left. We only know if there exists a next page or a previous page.

Could you still use the traditional pagination with pagesUnknown?

Yes - apparently the pattern described here is already supported.