-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[DataGridPro] Add data source interface and basic documentation #10543
Conversation
Deploy preview: https://deploy-preview-10543--material-ui-x.netlify.app/ Updated pages: |
|
||
By default, the data grid will use the tanstack react-query library to cache the data. A `QueryClient` is created internally and used with the data source. You can also pass your own instance of `QueryClient` in order to have access to the cached data outside the data grid. You can also use this client to invalidate the cache when you need to. | ||
|
||
In order to access the current keys for the `QueryClient`, you can wrap the application into the `DataSourceProvider`. |
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.
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.
Nice, do you think you could use the quick filtering in this demo instead?
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 think yes, by listening to the onFilterModelUpdate
and catching the filterModel.quickFilterValues
in the handler.
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.
Just for reference, even if we don't use tanstack query or some other external library, cache sharing should be possible with our internal cache too with the same basic principle. Instead of the cache available in the user's scope, the cache could be made accessible by apiRef
. (like apiRef.current.serverCache
for example)
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.
Looks like a good start! 👍🏻
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.
Some final refinements
Signed-off-by: Bilal Shafi <[email protected]>
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.
Great to see this page.
A quick round of review
@@ -0,0 +1,15 @@ | |||
--- | |||
title: React Server-side row grouping |
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.
title: React Server-side row grouping | |
title: React Server-side row aggregation |
|
||
# Data Grid - Server-side data | ||
|
||
<p class="description">The data grid server-side data</p> |
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.
<p class="description">The data grid server-side data</p> | |
<p class="description">The data grid server-side data.</p> |
- `updateRow` is optional | ||
|
||
`getRows` will be used by the grid to fetch data for the current page or children for the current parent group | ||
It may return a `rowCount` to update the total count of rows in the grid |
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.
It may return a `rowCount` to update the total count of rows in the grid | |
It may return a `rowCount` to update the total count of rows in the grid. |
sortModel: GridSortModel; | ||
filterModel: GridFilterModel; | ||
/** | ||
* Alternate to `start` and `end`, maps to `GridPaginationModel` interface |
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.
* Alternate to `start` and `end`, maps to `GridPaginationModel` interface | |
* Alternate to `start` and `end`, maps to `GridPaginationModel` interface. |
<DataGridPro | ||
columns={columns} | ||
dataSource={customDataSource} // this automatically means `sortingMode="server"`, `filterMode="server"`, `paginationMode="server"` | ||
/> |
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.
It overflows, it's hard to process:
<DataGridPro | |
columns={columns} | |
dataSource={customDataSource} // this automatically means `sortingMode="server"`, `filterMode="server"`, `paginationMode="server"` | |
/> | |
<DataGridPro | |
columns={columns} | |
{/* | |
This automatically means: | |
`sortingMode="server"` | |
`filterMode="server"` | |
`paginationMode="server"` | |
*/} | |
dataSource={customDataSource} | |
/> |
* Array of keys returned by `getGroupKey` of all the parent rows until the row for which the data is requested | ||
* `getGroupKey` prop must be implemented to use this | ||
* Useful for `treeData` and `rowGrouping` only |
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.
Overflowing in the page
* Array of keys returned by `getGroupKey` of all the parent rows until the row for which the data is requested | |
* `getGroupKey` prop must be implemented to use this | |
* Useful for `treeData` and `rowGrouping` only | |
* Array of keys returned by `getGroupKey` of all the parent rows until the row for | |
* which the data is requested. | |
* `getGroupKey` prop must be implemented to use this. | |
* This prop is only useful for `treeData` and `rowGrouping`. |
The data grid server-side data source has an initial set of required methods that you need to implement. The data grid will call these methods internally when the data is required for a specific page. | ||
|
||
```tsx | ||
interface DataSource { |
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.
We miss the prefix to make this type unique within all MUI products, no?
interface DataSource { | |
interface GridDataSource { |
x the other types
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.
Yep, nice catch, thanks!
title: React Server-side row grouping | ||
--- | ||
|
||
# Data Grid - Server-side aggregation 🚧 |
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.
Missing plan
# Data Grid - Server-side aggregation 🚧 | |
# Data Grid - Server-side aggregation 🚧[<span class="plan-premium"></span>](/x/introduction/licensing/#premium-plan 'Premium plan') | |
`` |
{ | ||
pathname: '/x/react-data-grid/server-side-data-group', | ||
title: 'Server-side data 🚧', | ||
plan: 'pro', |
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.
Are we sure about this one?
plan: 'pro', |
I can't find the Notion discussion about it but I had assumed that it's mostly upsides to make this match the features used in the data grid, since pagination is MIT, this would span all the plans.
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.
This is an interesting discussion. 👍
The decision was to not support the MIT features (i.e filtering, sorting, and pagination) with the data source (see existing server-side features section here), and I tried to cover under this section only those sub-sections that correspond to the server-side features bound to the data source. You are right, it might be confusing though as most users would think all the server-side features (including MIT) might be covered in the server-side data section.
Two possibilities we could go with:
- Go with the current assumption and alias the MIT corresponding features to the original sections and vice versa like this for example:
- Server-side filtering (MIT) linked to https://mui.com/x/react-data-grid/filtering/server-side/
- Server-side sorting (MIT) linked to https://mui.com/x/react-data-grid/sorting/#server-side-sorting
- Server-side pagination (MIT) linked to https://mui.com/x/react-data-grid/pagination/#server-side-pagination
- Or we could move all the server-side features (MIT and Pro) under the server-side data root section, create new sub-sections for filtering, sorting, and pagination, and have them cover both MIT (without data source) and Pro (with data source) sub-sections. The original sections for filtering, sorting, and pagination (linked in point no. 1) will then either have to be removed or aliased to the new sections.
What do you think?
@mui/xgrid Feel free to hop in
Part of #8179