[FormControl][material-next] Add FormControl component#39032
[FormControl][material-next] Add FormControl component#39032mj12albert merged 18 commits intomui:masterfrom
Conversation
Netlify deploy preview@mui/material-next: parsed: +0.23% , gzip: +0.19% Bundle size reportDetails of bundle changes (Toolpad) |
098f825 to
e00cfa4
Compare
e00cfa4 to
8e940b8
Compare
9210958 to
548da4a
Compare
7586fae to
2d2905d
Compare
DiegoAndai
left a comment
There was a problem hiding this comment.
Looks great overall 🎉
Just some small questions/comments
packages/mui-material-next/src/FormControl/FormControl.types.ts
Outdated
Show resolved
Hide resolved
| @@ -1,4 +1,6 @@ | |||
| // TODO v6: decide whether to update/refactor this, keep as-is, or drop it | |||
There was a problem hiding this comment.
What's the idea behind dropping/refactoring it?
There was a problem hiding this comment.
This is always used together with useFormControl like:
const muiFormControl = useFormControl()
const fcs = formControlState({
props,
muiFormControl,
states: ['color', 'disabled'],
});I was thinking it could be better to do this in a single hook, e.g.
const [
formControlState, // the result of `formControlState()`
formControlContext, // the result of `useFormControl()`
] = useFormControlState({
props,
states: ['color', 'disabled'],
})This would be internal, and wouldn't affect the original (public) useFormControl unless we wanted to (e.g. rename it to useFormControlContext or sth)
What do you think?
There was a problem hiding this comment.
I see. Adding a higher-level abstraction (useFormControlState) makes sense to me if we're using useFormControl and formControlState together all the time 👍🏼
We could create an issue and add it to the v6 milestone so we don't forget and can discuss the specifics whenever we have time.
86b8c52 to
c91f973
Compare
|
@DiegoAndai I fixed all the comments, and also fixed a mistake from before – the (I'm tempted to rename it |
Yeah, let's do that, either now or in the future. If not now, then let's create an issue and add it to the v6 milestone. The convention should be to use |
I've added an item in the TextField issue to follow up ~ Right now I would guess that it's named like that to indicate that it's going to the input slot instead of the root 🤔 // works
<FilledInput id="filled" defaultValue="Hello" inputComponent="textarea" />
// doesn't work – TS complains FilledInput/InputBase doesn't accept `component`
<FilledInput id="filled" defaultValue="Hello" component="span" /> |
mnajdova
left a comment
There was a problem hiding this comment.
Just one comment for clarification. It would be great if we have a playground page (maybe in the experiments folder) to check the component and test manually some of the functionality.
|
|
||
| const handleClick = (event: React.PointerEvent) => { | ||
| if (onClick /* && !fcs.disabled */) { | ||
| if (onClick) { |
There was a problem hiding this comment.
Why are we no longer checking for the disabled state?
@mnajdova I will include this with the next part which is |
Part of #38411, #29345
This PR refactors FormControl for v6
Summary:
It now internally uses
useSlotPropsAlmost all of the previously skipped InputBase tests are restored!
The refactor to use Base UI's FormControl component will be done separately, there are still some skipped tests at this point (dependent on some other components) so it would be better to restore those first
I have followed (at least) the PR section of the contributing guide.