Provide input widgets to easily build beautiful data manipulation forms in record time

[hlemcke]

This is a long one which probably might better be splitted into multiple issues :-)

Following the idea to build beautiful apps in record time,
I'm missing some easy to use widgets for data manipulation.

Since I'm far from being a Flutter expert, I just did some
research and some architectural base work.

My suggestion (still to be discussed and enhanced) is based
around these requirements:

a) provide an easy to understand package for data input
(data is more than just text)

b) supply data object to the form
(not each single value to each single field-widget)

c) Only write data access once in each single field-widget
(unlike 'initialValue' and 'onChanged' which are just like getter and setter)

d) Widget attributes with same functionality must have same names
(unlike 'initialValue' and 'value' or 'onChanged' and 'onValueChanged')

e) Put as much design to the form as possible
(can still be overwritten by children like each field-widget)

f) Each input widget should auto-assign itself to the form
(requires attribute 'path')

g) Each input widget should be usable stand-alone
(requires attributes 'initialValue' and 'onChanged')

h) Each input widget should accept a list of validators

i) Input validators should be reusable
(e.g. validators for 'NotNull', 'Min', 'Max', 'Future', ...)
Of course are some validators only usable for specific types of input values like
'Future' only makes sense for dates. Anyway there could be multiple input widgets
for dates.

So I came up with this suggestions:
(numbers are provided for reference, not for order)

1. Form extends StatefulWidget => exists
2. FormState extends State => exists
3. abstract Field extends StatefulWidget // T is the value type
4. Field.createState() will never be invoked by the framework
5. FieldState extends State<Field>
6. FieldState contains the current value of type T
7. InputWidget extends Field // T is the value type of this input widget
8. InputWidget.createState() => InputWidgetState
9. All InputWidget should have a ".adaptive" constructor like Switch
   (I don't know if this is possible, but would be great to have)

Comment for 8: do not provide a builder in InputWidget constructor when calling super.
This might make sense in TextFormField (small reduction of instance data)
but prevents access to instance data in InputWidgetState and its parent FieldState.
A better approach would be to have
FieldState.buildField( BuildContext context, Widget builder )
being invoked by InputWidget.build().

This design would make it easy to build additional input widgets.

Assigments of attributes could go like this:
(all field are optional unless otherwise noted)

Widget / Parameter / Type / Description

Form / key / Key / standard
Form / autovalidate / bool / =false. 'true' will validate input field on every change
Form / child / Widget / required. This one normally is a layout widget (e.g. Column)
Form / decoration / InputDecoration / used by subsequent input widgets, not by form itself
Form / enabled / bool / propagated to all fields below this form which did not overwrote it
Form / onChanged / ValueSetter / invoked on every value change of any 'InputWidget'
Form / onSaved / ValueSetter / invoked on 'Form.save()'
Form / onWillPop / as documented
Form / value / Map<String,dynamic> / map of nested values. Used by input widget as value

Field / key / Key / standard. Makes sense if input widget is stand-alone or for inter-field-dependencies
Field / autovalidate / bool / =false. 'true' invokes validate() on every value change. Overwrites 'autovalidate' of Form
Field / decoration / InputDecoration / label, error, hint, frame, ...
Field / enabled / bool / used when stand-alone. As form child overwrites Form.enabled which will not be propagated into this field
Field / initialValue / T / used to fill field.value. Precedence over using 'Form.value[path]'
Field / onChanged / ValueSetter / will be invoked on every change of the fields value
Field / onSaved / ValueSetter / will be invoked on Field.save() which also writes 'Form.value[path] = Field.value'
Field / path / String / used to access 'Form.value[]'. If null then 'onChanged' or 'onSaved' must not be null
Field / validators / List / invoked on 'Field.validate()'. First validator returning a string instead of null sets errorText of field and breaks the loop

InputWidget has all parameters of a Field plus its specific params.

Some methods are worth to be discussed as well:

InputWidgetState.initState()
	must invoke super.initState()

FieldState.initState()
	registers itself if a 'Form' predecessor exists.
	sets instance variable 'value' to 'initialValue'. If 'initialValue' is null then 'value = Form.value[ path ]'

FieldState.build()
	is an empty method which will never be invoked. Instead 'buildField' will be invoked by 'InputWidgetState.build()'.

FieldState.buildField( BuildContext context, Widget builder )
	uses parameter 'Field.enabled'. If null then uses current 'Form.enabled' (not attribute 'Form.enabled' from constructor!)
	returns an InputDecorator with child = builder and decoration = most appropriate decoration from field itself of from form or from somewhere above (?)

FieldState.save()
	if ( path != null ) then Form.value[ path ] = FieldState.value;
	if ( onSaved != null ) then onSaved( value );
	
FieldState.validate()
	for ( InputValidator validator in Field.validators) {
		if (( errorText = validator.validate()) != null ) then return false;
		}
	return true;

This will close issue #45609.

[iapicca]

Hi @hlemcke,
in my humble opinion the beauty of flutter is its modulartity;
I see that you feel the need to have a streamlined process
to "automatically" generate a form from a json,
but I'm not sure why this should be an "out-of-the-box" feature
when all the components you need to achieve this result are already available.

Again, my personal opinion, this would somehow prioritize to a user
the approach you have taken over any other, I'm not sure I'd like that;
what you are describing looks like an idea for a 3rd party plugin.

Have you considered creating a package to achieve the result you are asking for?
thank you

[hlemcke]

Hi @iapicca,

I have no intention to autocreate a form (like provided by NativeScript), because these forms look ugly and one of the big charms of Flutter is its beautiful design.

Instead I'm looking for the components as described above. You are right about the basic widgets. E.g. there is a "DropDownButton" but there also is a "DropDownButtonField". There is a "Switch" but there is no "SwitchField" and trying to have a Switch as a child of an InputDecorator renders the switch as wide as the whole horizontal space available (funny but ugly).

Some input widgets have value and onChanged but some have initialValue. Date and time pickers work completely different.

In which way will adjusting the existing Widgets change Flutter? I did not intend to prioritize my approach. Instead I'm trying to enhance Flutter and make it even easier to adapt to different approaches.

Providing this approach as a package is a good idea. I think I can spend enough time to develop the input widgets. Anyway I definitely prefer to have the basic classes Form, FormState, Field, FieldState provided and supported centrally (especially in concerns of rendering).

Would you at least agree with my ideas to unify the constructor parameters of the input widgets?

[iapicca]

Hi again @hlemcke
my question was about creating a package yourself and you have answer it,
thank you for that

[djarjo]

Hello. I have created a package https://pub.dev/packages/flutter_input which describes ad realizes the basics as written above.
Please have a look and a happy new year !!!

[Hixie]

@hlemcke It seems like @djarjo's package pretty much does what you're describing? I'm going to close this issue on the basis that there's a package that does it. Please don't hesitate to file a new issue if I misunderstood the proposal!