[Input] Reorganize the Input and Textarea components

[michaldudak]

Currently, the Input can act as either a single-line <input> or a multi-line <textarea>. This leads to unnecessary branching in code and a higher overhead (it is unlikely that the component will change from single to multiline during its lifetime).

Additionally, we have the TextareaAutosize component, that handles just the resizing feature of the textarea.

This is a proposal to remove the multiline feature from the Input and move it to the Textarea component (that could also include the autosize feature).

Search keywords:

[mj12albert]

There is a POC in the old repo for the Input part, I can finish it up in the new repo once Textarea is more or less done CC @michaldudak

[oliviertassinari]

@michaldudak As I understand things, either a developer needs:

a. an input, and he uses <input>
b. or he needs a textarea and he uses <textarea>
c. or he needs a variable height he uses <TextareaAutosize>
d. or he's building a Material UI kike project, he needs a kitchen sink: <Input> covers it, it's truly built for Material UI, just so that people ejecting the Material UI style to their repository keep the logic abstracted in an npm package.

So I don't understand this GitHub issue. What problem is there to fix?

The issue seems to suggest that developers building design systems should use <Textarea> or <Input>. What? I fail to envision one case where it would make sense. Outside of Material UI, why would someone building a design system not directly use the primitives? Today <Input> could be considered as full of "useless" code, only helpful in point d. above, because it wraps a bit of logic. Isn't his issue about that, saying Input is too high level? So why not go all the way to the bare level primitive?

I conclude that the right product experience is the current one, and that the right next step is to close this issue. #recommendation.

[michaldudak]

This comes from @colmtuite's audit: https://www.notion.so/mui-org/base-ui-Audit-0241b1291ff24c278ab1473f874c47d0?pvs=4#67e90e0c43fa4ac6a42f9c12775cfb25

It may turn out that the Input component is not needed in Base UI, and the native HTML input will suffice — we haven't designed it yet. Perhaps there will be value in having Form Control integration.

As for the textarea, I'd be in favor of simplifying the name of the existing component to just Textarea and provide and autosizing and (possibly, TBD) Form Control integration features.

[colmtuite]

@oliviertassinari My thinking was along the same as your options a, b, c, and d. This issue arose from that. Currently, you can turn an Input into a Textarea via a prop, which is confusing and useless. If you need a textarea, just use a textarea. So this is a proposal to remove that functionality from Input.

As Michal mentioned, it's looking like we have no use case for Input at all in Base UI, since people can just style a native <input type="text"> however they wish. Same goes for Button. We may include them to help them play nicely with <Form>, we'll see. Haven't looked closely at those components yet.

[mj12albert]

We have decided to deprecate TextareaAutosize mui/material-ui#43720

[michaldudak]

On the last team meeting we agreed to postpone this decision when we're closer to the release. We'll see if the browser support is decent enough for us to deprecate it.

[michaldudak]

Closing this to reduce duplicates. The TextInput component was created in #760 and we'll track the Textarea progress in #718

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.