@pedromassango failed test seems unrelated to this PR

Following your example in the issue (#107528), it doesn't feel it's that difficult to aggregate a bunch of TextFormFields? Developers would have to create a TextEditingController for each of them anyways so you could do

{ 
  'name': nameController.text,
  'email': emailController.text,
}

in the submit method?

here is a real world example that (in my opinion) hows how much better this approach scales and improves reusability. https://gist.github.com/casvanluijtelaar/a6db35fb984cb41b1c99b45d7bf570bd

failing tests seem unrelated to this change

Could you try syncing the branch to HEAD?

In case there're lazily built FormFields (e.g., in a lazy list) that haven't been built, calling submit would omit these fields. I think that is undesirable in a lot of cases?

In case there're lazily built FormFields (e.g., in a lazy list) that haven't been built, calling submit would omit these fields. I think that is undesirable in a lot of cases?

interesting case, a formfield that hasn't been built so hasn't been interacted with doesn't matter, they are skipped anyway. when a formfield has some state it will be cached in the form. So we can still get that data. Any issue cases I am missing?

Could you fix the error:

dartdoc:stdout: Generating docs for library widgets from package:flutter/widgets.dart...
dartdoc:stderr:   error: unresolved doc reference [FormState.submit]
dartdoc:stderr:     from widgets.FormField.submissionKey: (file:///tmp/flutter%20sdk/packages/flutter/lib/src/widgets/form.dart:375:17)
dartdoc:stderr:     in documentation inherited from widgets.FormField.submissionKey: (file:///tmp/flutter%20sdk/packages/flutter/lib/src/widgets/form.dart:375:17)

After looking at https://gist.github.com/casvanluijtelaar/a6db35fb984cb41b1c99b45d7bf570bd .I think the API seems to be a bit limited to be used for JSON serialization:

1. it can only be used to construct flat dictionaries, no nested structures or ordered collections. This may force the communication to use a flat, suboptimal schema.
2. the value is of type T and there's no way to specify how T should be serialized to JSON.
3. fields that have yet been built won't be included in the dictionary. This is often unexpected and the receiver may have to implement special handling for it.

Also

              FileField(
                submissionKey: 'file',
                hintText: 'important_file.pdf',
                initialValue: post?.file,
                validator: FeedFormValidators.fileValidator,
              ),

doesn't seem to be that much simpler than this:

             final fileFieldController = ....;
              FileField(
                controller: fieldFieldController,
                hintText: 'important_file.pdf',
                initialValue: post?.file,
                validator: FeedFormValidators.fileValidator,
              ),

, but with the controller approach you could do this:

{
  "attachments": { 
    "file" :  _fileToJSON(fieldFieldController),
  }
}

good points yes, and it would be difficult to implement these ideas with this approach, maybe we should look at exposing the Form _fields so we can build our own implementations around it and make better use of Forms powerful features.

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@casvanluijtelaar Checking in on your plans for this PR. Anything we can help with?

@casvanluijtelaar Checking in on your plans for this PR. Anything we can help with?

The work in this PR is good to go. I'd like to see it merged :). But if it's decided this isn't a good match I'd like to see _fields exposed so we can implement these interfaces ourselves.

I like what I see in this PR cause I was trying to achieve the same, instead of keeping myself references to all TextEditingController and even more complex form with files and dropbox where it start to be boilerplate and repetitive if you have multiple forms.

Having a submit method would help with that. Or as suggested at least expose _fields so we can do this kind of logic on our side so we can have that logic in one place and not do it for each form we need.

For reasons stated in #107530 (comment), I think using _fields for serialization could lead to hard-to-debug issues. Feel free to reopen this (or create a new PR) if you have new ideas to make it easier to work with Forms!.

After looking at https://gist.github.com/casvanluijtelaar/a6db35fb984cb41b1c99b45d7bf570bd .I think the API seems to be a bit limited to be used for JSON serialization:

1. it can only be used to construct flat dictionaries, no nested structures or ordered collections. This may force the communication to use a flat, suboptimal schema.
2. the value is of type T and there's no way to specify how T should be serialized to JSON.
3. fields that have yet been built won't be included in the dictionary. This is often unexpected and the receiver may have to implement special handling for it.

Also

              FileField(
                submissionKey: 'file',
                hintText: 'important_file.pdf',
                initialValue: post?.file,
                validator: FeedFormValidators.fileValidator,
              ),

doesn't seem to be that much simpler than this:

             final fileFieldController = ....;
              FileField(
                controller: fieldFieldController,
                hintText: 'important_file.pdf',
                initialValue: post?.file,
                validator: FeedFormValidators.fileValidator,
              ),

, but with the controller approach you could do this:

{
  "attachments": { 
    "file" :  _fileToJSON(fieldFieldController),
  }
}

Upon reading and taking the time to consider the above points, I'm left wondering if the solution that this PR proposes is in fact suboptimal.

1. I agree that the result would be a flat dictionary. However, I'm not convinced that this would be an issue for the developer. It would help me better understand the concern if an example scenario were provided showcasing where this would be an issue.

2. You're absolutely correct on this point. In the author's example, they call fromJson with the result of submit. I think this would be considered a mistake on the developer's part to assume that the result of submit is serialized. A form field's value ("T") shouldn't need to be serialized by Flutter. That would be left to the developer. The submit button only gives you a dictionary of keys and values that represent the form fields. It does not guarantee the resulting dictionary contains serialized values. Creating serialized values would be the responsibility of the developer once they have the dictionary result.

3. That's a good point. I'm curious as to how Flutter currently handles this when FormState.save() is called. I imagine that onSaved isn't called for the FormField widgets that haven't been built, seemingly leaving the developer in a similar scenario as this solution—similar, but not the same. Perhaps documentation could address this concern by stating that only the values of FormFields that have been built will be returned.

As for the use of controllers, they certainly work beautifully for many scenarios, but not all. Some FormFields are not able to use them. For example, DropdownButtonFormField doesn't have a controller since controllers are not part of the FormField api. Additionally, controllers tend to introduce a lot of boilerplate code which can feel disruptive to the developer experience when used only for the sake of accessing the value of a form field.

Truly, it would be a poor argument to state that the solution proposed by this PR is good simply because it follows the same design, for retrieving form field values, as other popular Flutter form libraries on pub.dev. However, the fact that these libraries have a fair amount of developers showing support for them does highlight a desire path created by the Flutter community for an improved form building experience, and the solution this PR proposes would indeed improve the form interface by making it significantly easier to retrieve form values. As a result, I think introducing a solution like this to the Flutter SDK is worth reconsidering so long as we can refactor it to address the concerns pointed out by @LongCatIsLooong.

Hey @LongCatIsLooong 👋, I hope all is well! I'm just checking in to see if you were able to take a look at the comment I made. I'm hoping to see if we still can work to address the concerns you raised with this PR.

@jaumard, it looks like @LongCatIsLooong might be assisting with different issues on the Flutter GitHub at the moment. Would you be willing to consider reopening this issue after reading my above comments? I'd like to see if we could still address the concerns, in this PR, that @LongCatIsLooong brought up.

Sorry for the late reply. Exposing _fields under a descriptive name (ideally something that tells people this property may not be a comprehensive list of fields, some fields could be omitted) sounds reasonable to me. Then you could build convenience extensions on top of the property.

Upon first glance at the _fields property, I was concerned that it might cause unexpected bugs if we exposed the underlying Set, but after taking a closer look this time, I think it might actually be fine. It doesn't look like anyone is creating a PR for #110760; so, perhaps I will.