-
-
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
[DataGrid] Differenciate the pro and community versions of GridState
, GridApi
and GridApiRef
#3648
[DataGrid] Differenciate the pro and community versions of GridState
, GridApi
and GridApiRef
#3648
Conversation
… GridApi and GridApiRef
These are the results for the performance tests:
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@m4theushw I have an implementation passing all the CI steps. There are some cleaning to do on the doc generation, but I want to do the bundle split before because half of my work is going to be dropped after the split. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
👋 The migration PR has been merged. Please follow these steps to make sure that the contents are all updated. (Sorry for the inconvenience)
If you are struggle with the steps above, feel free to tag @siriwatknp |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
I am merging this one to be able to move on without blocking the releases for to long. |
Part of #924
Goal
To reduce the amount of imports from file that should be moved to the
x-data-grid
package to files that should be moved to thex-data-grid-pro
package.New behavior
Interface based on the package
If you import
GridApi
,GridState
orGridInitialState
from@mui/x-data-grid
, you will have the community version.If you import
GridApi
,GridState
orGridInitialState
from@mui/x-data-grid-pro
, you will have the pro version.Internally we use
GridApiPro
andGridApiCommunity
while waiting for the bundle split.Afterwards, we should be able to simplify things.
For all the interfaces depending on the api (for instance
GridRenderCellParams
to type itsapi
param orGridColDef
to type itsrenderCell
params throughGridRenderCellParams
), I added anApi
generic which extendsGridApiCommon
.When exported from
@mui/x-data-grid
, the default generic value is the community api, when exported from@mui/x-data-grid-pro
, the default generic value is the pro api.Untyped interfaces
Some use case were to complicated to cover for now.
For instance, the
columns
prop ofDataGrid
has the typeGridColumns
. Otherwise, you could have errors when passing pro columns to the community version because TypeScript consider that the pro and community api are not compatible.createSelector
The method now ask as a parameter the largest state used in one of its sub-selectors.
For instance the following selector will ask for
GridApiPro
becausegridRowGroupingModelSelector
is a pro selector.Note: Everything still works with the
apiRef
, I just simplified the typing to accept a ref which extends{ instanceId: number, state: S }
What's next ?
In v6 we should drop all the
api
parameter to reduce as much as possible the scope of the plan-based typing.This requires to open the
apiRef
to the community plan (which should be fairly easy after this PR).