-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[Data Grid] Add recipe for cursor pagination with data source #19700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Deploy preview: https://deploy-preview-19700--material-ui-x.netlify.app/ Updated pages: Bundle size report
|
…o docs/cursor-pagination
…o docs/cursor-pagination
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I'll defer the approval to @MBilalShafi who has more insight into this feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we block the switching of the next page in this demo like the one in unknown case here until the page being fetched has been fetched to avoid incorrect values set for all the skipped pages?
Screen.Recording.2025-10-20.at.23.44.49.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the methods getLast and pushKey are used in the userland and not used internally, for a better separation of concerns, does it makes sense to use the default data source cache (not pass a custom one) and maintain a separate class encapsulating cacheKeys, getLast, and pushKey in the userland and consume it in the dataSource.getRows() method?
If needed, it can interact with the internal cache using apiRef.current.dataSource.cache.
Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so.
apiRef.current.dataSource.cacheis not documented yet- it sounds more complicated than let user handle their own cache (there could be project specific logic that we haven't think of), so for simplicity, let's use a custom cache implementation which is already documented.
| columns={columns} | ||
| dataSource={dataSource} | ||
| dataSourceCache={cache} | ||
| pagination |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add an error handling (onDataSourceError()) to this demo, causing the page to reset on the last loaded one if one of them fails?
Because all the responses are chained together, if one of them fails, the view will remain into loading state forever.
Example: https://stackblitz.com/edit/gy5p4ufa?file=src%2FDemo.tsx
Screen.Recording.2025-10-21.at.00.03.43.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I think if there is an error, the page will have to reset back to the latest success query
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is updated version with error handling. I set the error to happen on page 8 to demonstrate the error handling. I took this approach because it's the simplest one.
I tried to use onDataSourceError but it does not work well for this non-blocking demo.
Screen.Recording.2568-10-21.at.16.52.03.mov
…o docs/cursor-pagination
closes #16674
closes #18878
Preview: https://deploy-preview-19700--material-ui-x.netlify.app/x/react-data-grid/server-side-data/recipes/#cursor-based-pagination
Summary
This PR enhances the Data Grid documentation by adding comprehensive examples and explanations for cursor-based pagination, addressing a common server-side data pattern where traditional offset pagination isn't suitable.
Changes
Documentation Updates
docs/data/data-grid/server-side-data/recipes.mdNew Demo Components
ServerSideCursorBlocking.js- Blocking approachpaginationModelstate to ensure cursor availabilityServerSideCursorNonBlocking.js- Non-blocking approachpushKey()andgetLast()methodsTechnical Implementation
Blocking Approach
mapPageToNextCursorref to track cursorsNon-blocking Approach
Benefits
paginationMetaand custom caching