[FormControl] Add useFormControlState #16467
Conversation
Details of bundle changes.Comparing: 73e9950...4c6b8dd
|
eps1lon
force-pushed
the
feat/useFormControlState
branch
from
81a0e07
to
8e90ac7
Compare
eps1lon
force-pushed
the
feat/useFormControlState
branch
from
0c0774c
to
4c6b8dd
Compare
| @@ -1 +1,2 @@ | |||
| export { default } from './FormControl'; | |||
| export { useFormControl } from './FormControlContext'; | |||
There was a problem hiding this comment.
What do you think of merging this hook with the formControlState helper? #11865 (comment)
There was a problem hiding this comment.
I mean, what's the best API to expose publicly?
There was a problem hiding this comment.
Just expose the state? Why do you think formControlState should be included?
There was a problem hiding this comment.
I personally have a slight preference for not exposing formControlState. This is a module we use for merging the context with the props values. People asking for accessing the form state might not need it (if they do, they can handle it on their side). However, I'm asking because people tracking #11865 might expect formControlState to be public based on my previous comment. Should we collect their feedback?
Ok, maybe we can go for it, collect feedback once released, the future cost of change will be minimal.
oliviertassinari
added
the
component: text field
Going to come up with an example later. The point was to rewrite the test so that we don't rely on the internal
FormControlContext.Providerand the onEmpty/onFilled callcounts. It's very likely that they will change soon anyway and I don't want to battle with internals. The important bit was thatfilledis propagated not how many times these handlers were called (since nobody taps into them anyway and we accepted buggy behavior).Closes #11865
Follow-up:
withFormControlwithuseFormControl(deferred since no immediate benefit).