[FormControl] Expose the form control state

[serle]

How does one get the Context managed by a <FormControl/> into one's own component that is intended to be a child of the <FormControl/>. The form control does not seem to pass disabled, focused, error as properties and also does not use React's new context API. Could you add this answers to the documentation somewhere.

[oliviertassinari]

@serle You can't. It's an implementation detail.

[serle]

@oliviertassinari If the purpose of the FormControl is to act as the source of filled, focused, error states and then we should be able to use it as a building block for our own controls. It would be great if it could pass these as props to its direct children as well as expose some callbacks to be able to set these.
I'm essentially re-using FormLabel and FormHelperText, but creating my own child control for content that does not fit into the standard Input, Select etc. controls.

[oliviertassinari]

@serle I think that we could be exposing the context consumer component once we migrate to the next API.

[serle]

@oliviertassinari great, could you remember to include an update function in the context as well so that we can update these state variables from the child components, if necessary

[eps1lon]

What are the use cases for this feature? I'm hesitant to expose internal variables just for the sake of it. Which values would be useful and why?

@serle What are the use cases for this feature? You can already change the values of disabled, error, margin and required via props of FormControl. Adding an update function to change this values can be problematic as with all cases were you mix potential sources of a value (state, props and context). Values like focused and filled already have a private update function.

[serle]

@eps1lon I hit this problem when I wanted to create my own FormControl and have child components notify the form control that they have an error, are filled, are set back to their pristine value.

On the other hand I have an overall Form component with all of these child FormControl components and I need to enable and disable/enable the save and discard for the overall Form. The Form component then needs a way to either call down to each of its FormControl component to consolidate an overall form state e.g. filled, error etc or have the FormControls notify the parent Form component that there is an internal state change e.g. filled, error etc, so that the Form component can maintain an aggregate version of this. As far as I can tell there is no concept of a Form component. In my case I go a step further and have the following hierarchy Form->Panel->FormControl, with state rollup.

It would be great for introduce this type of higher-order Form behavior into your library so we can have chunked up Form which cater for more complex data structures.

[eps1lon]

If you already have your own FormControl why not wrap this in your own context that sets the props. This is similar to controlled vs. uncontrolled components. Our FormControl is currently fully controlled. Mixing in an internal controller via context that can be updated can cause all sorts of issues which is why react docs recommend using either a fully controlled or uncontrolled component.

You're already in control of the props you pass to our FormControl. How you want to update those is a concern for your codebase (redux, context, mobx etc). Filled should already be handled by our input components.

[sarod]

It would be useful for me to have FormControlContext.Provider exposed as part of the API to support implementing custom Input, InputLabel or FormControlLabel.

In my case I agree that there is no need to update FormControlContext from parent without using props. Handlers (onBlur, ...) exposed on FormControlContextProps are enough to communicate from child component to FormControl.

Also reading the documentation it is unclear if FormControl could be used as a building block for custom inputs.
The following sentence makes me think it should be usable by custom inputs:
Relying on the context provides high flexibilty and ensures that the state always stays consistent across the children of the FormControl.

[eps1lon]

Could you add and example of a custom implementation and why we would need to support this? It's not as simple as simply making something public.

The following sentence makes me think it should be usable by custom inputs:
Relying on the context provides high flexibilty and ensures that the state always stays consistent across the children of the FormControl.

Quoting the full paragraph should make it clear that it's used by material components.

To be honest I have to look into this myself because we state that only one input can be used but we use it in our demos for multiple e.g. radios. So the documentation might have some room for improvements.

[sarod]

@eps1lon I have two concrete usecases as of today.

First is to implement a drop in replacement for InputLabel that embed customization in the label that would integrate with existing Input and FormCotnrolHelperText through FormControl. In my case the customization is adding an additional "documentation" button that is part of the label but still needs to ba aware of the FormControl state to style itself accordingly.

The second is to implement a custom Input that would integrate with existing InputLabel and FormControlHelperText here again through FormControl. In my case the custom input is based on monaco editor.

[mfolnovic]

I'm implementing a wrapper controlled component (with styling and some additional functionality) around TextField. I'm using Storybook for testing/documenting this.

I would like to be able to write a story that "forces" this component in other states (e.g. focus).

From code, I inferred this could be done by exposing FormControlContext, which is why I'm writing my use case in this issue. :)

It would be easiest if I could write something like:

<FormControlContext.Provider value={{focused: true}}>
  <TextField ... />
</FormControlContext.Provider>

[ianschmitz]

@oliviertassinari - continuing conversation from #16049.

Here's a very high level implementation of how we use FormControlContext in a custom component composed of MUI components.

function ColorInput(props) {
    const { muiFormControl, onChange, value } = props;
    const fcs = formControlState({
        props: props,
        muiFormControl,
        states: ["disabled"],
    });

    return (
        <div>
            <Input onChange={onChange} value={value} />
            <Button disabled={fcs.disabled} />
            <Popover>...</Popover>
        </div>
    );
}

export default withFormControlContext(ColorInput)

Usage:

<FormControl disabled={disabled} required={required}>
  <FormLabel htmlFor="input-color">Normal Width Color</FormLabel>
  <ColorInput
    id="input-color"
    value={this.state.colorValue}
    onChange={this.handleColorChange}
  />
</FormControl>

[oliviertassinari]

Interesting, we will remove withFormControlContext in the near future. I propose we replace it with a useFormControlState (#15231).
I believe that we could expose this hook.

[ianschmitz]

@oliviertassinari sounds like a good plan. In our situation we only use the HOC to forward the control to formControlState. The hook would be fantastic.

[oliviertassinari]

While it might be more challenging than the other good first issues, I'm adding the flag. It's relatively simple, the only thing left that could stop to make it happen is somebody from the core team having none already revealed concerns with the approach.