-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[core] Use MUI Core v7 libraries in packages and docs #16771
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
Conversation
527020b
to
0f035a8
Compare
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
The deploy, codesandbox, and types failures should be fixed with mui/material-ui#45491 |
@Janpot @cherniavskii @LukasTy in the last commit, I fixed some TS issues that surfaced:
I wonder why these weren't caught earlier 🤔 any ideas? After fixing these, we have two types errors left, which are being handled in mui/material-ui#45548 I think we should split these fixes off into separate PRs, but wanted to check with you first. |
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.
Thank you for working on this! 🙏
The changes make sense to me. 👌
@@ -388,11 +388,11 @@ function transformInputProps(props: GridSlotProps['baseInput'] | undefined) { | |||
result.endAdornment = <InputAdornment position="end">{result.endAdornment}</InputAdornment>; | |||
} | |||
|
|||
if (slotProps?.htmlInput) { | |||
if (slotProps?.input) { |
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 and the change in gridBaseSlots
might be a slight breaking change, which should be flagged. 🤔
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.
Where should I do that?
Also, should I start creating separate PRs for each of these fixes?
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.
Maybe @mui/xgrid could assert it and handle it accordingly? 🤔
It looks like this might have been a mistake all along. 🙈
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.
What slotProps
should be used for the HTML input element? Did it change?
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.
- In the
Input
components,slotProps.input
points to the input HTML element - In the
TextField
component,slotProps.htmlInput
points to the input HTML element, andslotProps.input
to theInput
component
It hasn't changed
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.
Ok. So the slotProps
here aren't material slotProps
, they're data-grid baseInput
slotProps
which have their own independent set of typings. I didn't notice that nuance in material props when I wrote the grid base slot typings, so I made htmlInput
refer to the HTML input element for both baseInput
and baseTextField
.
The grid base slots are inspired by material API but don't match it in many places. It's possible that we keep using htmlInput
in both cases, and I think it's going to be more intuitive for grid-bindings authors reading those typings, so I'd keep it as it is. Any thoughts on that?
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.
Thanks for clarifying. 👍
Yeah, it makes sense to me, in such case, the changes made by Diego should be reverted. 👌
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.
Ok, we have a problem if we revert this change.
Docs examples with Material components start failing prop checking, because they do not expect to receive slotProps.htmlInput
on a InputBase slot. 🙈
So, this also potentially means a BC for users if we go with some sort of override. 🤔
Either we need to rename the slotProps to input
as initially done by Diego or consider alternative typing approaches. 🤷
WDYT @romgrk? Does the current state make sense?
InputBase
component never had a htmlInput
slot, it was always input
, so, if I understand it correctly, material migrating to slotProps
triggered this error as now the typing is very close, but different, while before there were no slotProps
. 🤔
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.
material migrating to slotProps triggered this error as now the typing is very close, but different
In this case it's close but different, but in other cases it's completely different.
Docs examples with Material components start failing prop checking, because they do not expect to receive slotProps.htmlInput on a InputBase slot.
Why is an InputBase
receiving those props though? The grid baseInput
is not an InputBase
, typecheck should not fail. Which examples are failing?
edit: I've found the issue, let me get some feedback from the rest of the team.
The changes in screenshots seem innocent, but do we know what in this PR caused them? |
Please try merging the latest master to see if that fixes it. 😉 |
Maybe it's the bump of |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
packages/x-charts-pro/package.json
Outdated
@@ -53,8 +53,8 @@ | |||
"peerDependencies": { | |||
"@emotion/react": "^11.9.0", | |||
"@emotion/styled": "^11.8.1", | |||
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-alpha", | |||
"@mui/system": "^5.15.14 || ^6.0.0 || ^7.0.0-alpha", | |||
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-beta", |
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.
would it make sense to already define the full v7 range so that we don't have to make changes to test with stable core once it gets release. We then just have to remove ^7.0.0-beta
once X goes stable.
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0-beta", | |
"@mui/material": "^5.15.14 || ^6.0.0 || ^7.0.0 || ^7.0.0-beta", |
🤔 I believe we can do this both for dependencies and peer dependencies
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.
Whoops, somehow I might have missed something. 🙈
Clearly, I agree with the proposal. 👌
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.
And I'm just still wondering about the dev dependencies. I feel like we should think about how this will look in stable v7 world. i.e. every time we'd write
"@mui/material": "^7.3.8"
we'd want that to look like
"@mui/material": "^7.0.0"
At the time of X@v8 going stable. And thus today, in beta, we want that to look like
"@mui/material": "^7.0.0 || ^7.0.0-beta"
or
"@mui/material": "^7.0.0 || ^7.0.0-beta.4"
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.
Does it matter that much if we plan to remove the beta
dep after a stable release?
Technically, we could have probably left ^7.0.0-alpha.0
to be precise, if there are no specific fixes afterwards, that would prevent interoperability. 🤔
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's not as important as it's not user facing. We can update it as well when core@v7 becomes stable.
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 a suggestion about widening the dependency range a bit more, otherwise looking good
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@mui/material
and related packages.Changelog
@mui/material
has been updated to accept only v7.This has been done to increase the adoption rate of ESM.
Since only v7 of
@mui/material
has proper ESM support, we decided to help with its adoption and fix numerous issues using X packages in environments where transpiling is not an option.TODO