[RFC][Joy UI] Remove `TextField` in favor of composition

[siriwatknp]

Problems

The TextField is a wrapper of FormLabel, Input, and FormHelperText. It binds the id with ARIA to those components which reduce a lot of effort for developers.

However, it becomes a pain when you need to pass props to the inner HTML input:

Hard to customize

To pass a prop to the HTML input, you have to do this:

<TextField
  componentsProps={{
    input: {
      componentsProps: {
        data-attributes: '',
      }
    }
  }}
/>

Confusion

Take Material UI as an example, Joy UI would follow the same regardless of the final APIs for the TextField.

here is some confusion from the community about the API of the TextField:

• https://github.com/mui/material-ui/issues/31421
• https://github.com/mui/material-ui/issues/29525
• https://github.com/mui/material-ui/issues/11377

Proposal

Remove the TextField component and lean toward composition similar to Chakra UI.

<FormControl>
  <FormLabel>...</FormLabel>
  <Input /> {/* This could be Textarea, Select, Autocomplete */}
  <FormHelperText>...</FormHelperText>
</FormControl>

I think the removal of the TextField will clean up the confusion and hand over the customization to developers which sounds like a good strategy for us (as a maintainer).

Advantages

• I believe that it will reduce the issues related to the props injection for Joy UI.
• Low learning curve because it is one-to-one DOM mapping.
• It is easier to customize both styling and passing props.
• Don't need to spend time thinking about the API that the TextField should have (currently, the componentsProps does not work)
• The pattern can be used with Textarea, Select, and Autocomplete without creating new field components.

Disadvantages

• More character to type (I don't think this is a big deal because Chakra UI has positive feedback)
• Different experience compare to Material UI (does it matter that much? Material UI also provide FormControl for composition as well)

[kabernardes]

Hi, can I try this one?!

[siriwatknp]

Hi, can I try this one?!

Thanks for asking but I think we will have to wait for the decision first.

[oliviertassinari]

I think that this could work as long as the abstractions terminology/structure is compatible with Material UI's one.

At a high level, I would be amazed if we don't get a lot of people asking us to create a Text Field abstraction on top of the lower-level primitives once we remove it, but who knows? It might actually be interesting to experiment.

In v1, I tried to promote the composable API https://v1.mui.com/demos/text-fields/#components but move the h2 lower in the page in the following major versions when I saw the Google Analytics demos use stats on this page 😁.

[WilliamKelley]

[TextField] binds the id with ARIA to those components which reduce a lot of effort for developers.

This is the most important aspect of the solution for me. If the alternative can do this by default, then I'd be satisfied.

[siriwatknp]

[TextField] binds the id with ARIA to those components which reduce a lot of effort for developers.

This is the most important aspect of the solution for me. If the alternative can do this by default, then I'd be satisfied.

Yes, it works the same.

The only downside is that you have to write more code (3 components) instead of 1, the TextField.

[WilliamKelley]

[TextField] binds the id with ARIA to those components which reduce a lot of effort for developers.

This is the most important aspect of the solution for me. If the alternative can do this by default, then I'd be satisfied.

Yes, it works the same.

Great! I can add that I think this would be received well by my company engineering team. Those who are very comfortable would grunt at the loss of a succinct component, but I've fielded so many questions and misunderstandings about TextField and TextField vs FormLabel, Input, etc. that it would have been well worth it to everyone to never have dealt with the abstraction in the first place.

One more thing I'd like to suggest is making Form*** components warn in the console if they can't find a FormControl context. My aim is to have a safety net to avoid using them in an inaccessible manner. I can't think of a good reason to use outside of a FormControl.

[siriwatknp]

From https://github.com/mui/material-ui/pull/34994, using Input directly instead of the TextField let me focus on the composition to create a horizontal text field without banging my head with the TextField customization.

[oliviertassinari]

Related to this discussion https://twitter.com/BrettThurs10/status/1591118613318369281

[hbjORbj]

Jun, as we discussed, I made a draft PR for this issue. Feel free to skim through.

Since Joy doesn't have API docs yet, should we at least have a documentation for Joy FormControl so that developers can figure out how to create a user input?

[Dooblr]

Is TextField still being removed? It remains in the package.