Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Input] Reorganize the Input and Textarea components #71

Open
michaldudak opened this issue Jan 15, 2024 · 6 comments
Open

[Input] Reorganize the Input and Textarea components #71

michaldudak opened this issue Jan 15, 2024 · 6 comments
Labels
component: input This is the name of the generic UI component, not the React module! on hold There is a blocker, we need to wait

Comments

@michaldudak
Copy link
Member

michaldudak commented Jan 15, 2024

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 mj12albert self-assigned this Jan 19, 2024
@michaldudak michaldudak transferred this issue from mui/material-ui Feb 27, 2024
@michaldudak michaldudak changed the title [base-ui] Reorganize the Input and Textarea components [Input] Reorganize the Input and Textarea components Feb 27, 2024
@michaldudak michaldudak added the component: input This is the name of the generic UI component, not the React module! label Feb 27, 2024
@mj12albert
Copy link
Member

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
Copy link
Member

oliviertassinari commented Mar 10, 2024

@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
Copy link
Member Author

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
Copy link
Contributor

@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
Copy link
Member

We have decided to deprecate TextareaAutosize #165

@michaldudak
Copy link
Member Author

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 michaldudak added the on hold There is a blocker, we need to wait label Mar 27, 2024
@mj12albert mj12albert removed their assignment Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: input This is the name of the generic UI component, not the React module! on hold There is a blocker, we need to wait
Projects
Status: Selected
Development

No branches or pull requests

4 participants