-
-
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] Rename components
and componentsProps
props
#7059
[DataGrid] Rename components
and componentsProps
props
#7059
Conversation
components
and componentsProps
props
@DanailH With @joserodolfofreitas , we discussed keeping both names during v6. @alexfauquette will do the implementation on the picker side. |
These are the results for the performance tests:
|
We have briefly discussed it last week and it sounded like we were leaning toward the same approach as Material UI (option 2 in #6986). |
Perhaps it's a better idea to try closing this topic earlier at the General meeting tomorrow, we'll have more time to discuss the trade-offs. From DX side, I think it's positive to keep both APIs (during v6) and provide consistency for users using Material UI. It's also generally a more friendly approach, which is particularly important when updating one of the core concepts for customization. The negative aspect I see is the possibility of users relying too much on copying and pasting and ending up with both the slots and components set, which in this case, they should be warned that only slots property will be considered (however, that's also a realistic scenario if we make the breaking change now). From the development side, as I understand, we'd have to maintain (during v6) a few duplicated APIs and types. I guess most of the deprecation warnings and error treatment would be the same, probably with some additional logic conditional statements. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@@ -13,7 +13,7 @@ import { | |||
import { useBasicDemoData } from '@mui/x-data-grid-generator'; | |||
import { getCell, getRow } from 'test/utils/helperFn'; | |||
|
|||
describe('<DataGridPro/> - Components', () => { | |||
describe('<DataGridPro/> - slots', () => { |
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.
describe('<DataGridPro/> - slots', () => { | |
describe('<DataGridPro/> - Slots', () => { |
@@ -11,7 +11,7 @@ import { spy } from 'sinon'; | |||
import { DataGrid, GridOverlay } from '@mui/x-data-grid'; | |||
import { getCell, getRow } from 'test/utils/helperFn'; | |||
|
|||
describe('<DataGrid /> - Components', () => { | |||
describe('<DataGrid /> - slots', () => { |
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.
describe('<DataGrid /> - slots', () => { | |
describe('<DataGrid /> - Slots', () => { |
const components = React.useMemo<GridSlotsComponent>(() => { | ||
const overrides = themedProps.components; | ||
const slots = React.useMemo<GridSlotsComponent>(() => { | ||
const overrides = themedProps.slots; |
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'll need to continue extending from components
while MUI Core has not renamed the prop on their side.
const overrides = themedProps.slots; | |
const overrides = themedProps.components; |
@@ -86,7 +86,7 @@ export type DataGridForcedPropsKey = | |||
* The `DataGrid` options with a default value that must be merged with the value given through props. | |||
*/ | |||
export interface DataGridPropsWithComplexDefaultValueAfterProcessing { | |||
components: GridSlotsComponent; | |||
slots: GridSlotsComponent; |
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 need to decide which approach to follow:
- Keep only
slots
- Only support
slots
and show a warning ifcomponents
is used - Recommend
slots
but continue supportingcomponents
with a warning
cc @mui/x
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'd say go for no. 3 for v6. It'll ease down some of the migration pain. Probably remove completely in v7?
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.
supporting components with a warning
Maybe mark those props as @deprecated
instead of a warning in the console?
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.
https://www.notion.so/mui-org/X-General-Meeting-2022-12-02-ef4eac5767114e40abed748bf592e69e
We went for the @deprecated
indeed
Should we additionally follow these conventions too? (From mui/material-ui#34693)
I think pickers followed it (at least the |
Has been handled in #7882 |
Fixes #6986
Breaking change
PS: @flaviendelangle it probably makes sense to do the same change for the pickers