Repository navigation
Need to rationalise the names of the *Input* and *Field* classes #7031
Description
As of today:
InputField is not an Input and is not a FormField. It contains a RawInput.
InputContainer is not an Input and is not a Container.
Input builds an InputContainer containing an InputField.
InputFormField extends FormField and builds an Input.
This is very confusing. We should rationalise these names.
See also #7017 about documenting all this better.
Activity
HansMuller commentedon Nov 28, 2016
Also, per #6733 (comment), in the Material spec and in many GUI toolkits, Input is called TextField.
mpcomplete commentedon Dec 8, 2016
Proposal:
Input => TextField (to match Material spec)
InputContainer => TextFieldDecorator
InputField => TextFieldEditable
InputFormField => TextFormField
Let's decide on this soon. The longer we wait, the more people we will break.
Hixie commentedon Dec 9, 2016
InputContainer/TextFieldDecorator isn't just about Inputs/TextFields. How about something like ControlLabel or something for that one?
Form uses FormFields. TextField and FormField sound like they'd be related, but aren't in this model.
I like that today InputFormField is a FormField.
I do like the TextField name, that makes sense to me. We could find another term for FormField, maybe FormControl? then you can have TextFieldControl for the version of TextField that is a Control. Or TextFieldFormControl but that's a bit long.
RawInput could be RawTextField. Today's InputField is between TextField and RawInput, maybe PlainTextField? But that suggests it's a "plain-text field", as opposed to a "plain text-field". Maybe UndecoratedTextField?
What does TextField add? Could we drop it and require that people either use TextFieldControl or ControlLabel+PlainTextField? In which case we could rename that latter one to just TextField? But then it's weird that TextFieldControl does more than just add the FormControl to the TextField, it also adds the ControlLabel...
In general, if Foo is a class, then BarFoo should be a subclass of Foo that adds bar-related functionality, and FooBaz should be a helper class for Foos that handles baz-related logic.
mpcomplete commentedon Dec 12, 2016
I like UndecoratedTextField. It's the most accurate description. I suspect most people won't use it anyway.
TextField is the Material-spec implementation and should be most common, so I think we should keep that.
I also like the Foo => BarFoo naming convention. I was trying to avoid the repetition of "Field", but maybe that's not worth it.
Something about "FormControl" seems wrong to me. Maybe it's just me.
New proposal:
RawInput => RawTextField
Input => TextField
InputContainer => TextFieldDecorator
InputField => UndecoratedTextField
InputFormField => TextFieldFormField or TextFieldFormControl (these options are my least favorite)
Hixie commentedon Dec 12, 2016
InputContainer is for any kind of form control, right? Not just text fields.
In general I would avoid a name FooBar if both Foo and Bar are classes because that's confusing (is it a subclass of Bar, or a utility class for Foo?).
Hixie commentedon Dec 12, 2016
RawTextField/UndecoratedTextField/TextField seems good to me.
I think we should broaden the scope of renames to include Form, FormField, and FormState (which by the way has no documentation). (Not saying we need to rename all of these, just that including them in the list is good for noticing if your names are consistent.)
mpcomplete commentedon Dec 12, 2016
Oops you're right, I glossed over InputContainer for some reason. That one's hard to name, because it's such a weird grab bag of stuff. WidgetThatAddsSomeTextFieldLikeDecorationsToChild would be accurate...
Hixie commentedon Dec 12, 2016
Maybe InputFieldDecorator or something like that?
abarth commentedon Dec 13, 2016
Here's a slate:
Hixie commentedon Dec 13, 2016
What is FormAssociatedWidget?Oh, I see, the current FormField.abarth commentedon Dec 13, 2016
Yes. It's a base class for other widgets, which with tend to name either with a "Widget" suffix (e.g., AnimatedWidget) or with an "able" suffix (e.g., Pageable).
Hixie commentedon Dec 13, 2016
One thing is that EditableText is material-specific (it uses material UI for its popup menu). It's weird that we'd have a RawEditableText in widgets/ an EditableText + TextField in material/. I think Matt's UndecoratedTextField/TextField might be better.
abarth commentedon Dec 13, 2016
Ah, I missed that UndecoratedTextField was material-specific. It's usually a bad pattern to name something after what it isn't. Maybe RawTextField?
23 remaining items
abarth commentedon Mar 31, 2017
New proposal:
abarth commentedon Mar 31, 2017
Also, InputDecoration, which bundles up all the consty parameters to InputDecorator to make them easier to deal with.
Hixie commentedon Mar 31, 2017
SGTM
Rationalize text input widgets (#9119)
github-actions commentedon Sep 5, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.