Skip to content

exposing FormState _fields value #110760

Closed

Description

@casvanluijtelaar

Use case

the form widget can be a powerful tool as it caches and can interact with all its child FormField without having to manually track them through keys. this is useful for a couple build in features like submitting & saving. but blocks the user from creating it's own implementations like for example #107530

Proposal

make the FormState _fields value into a public field so we can use it to extend its functionality

/// State associated with a [Form] widget.
///
/// A [FormState] object can be used to [save], [reset], and [validate] every
/// [FormField] that is a descendant of the associated [Form].
///
/// Typically obtained via [Form.of].
class FormState extends State<Form> {

  final Set<FormFieldState<dynamic>> fields = <FormFieldState<dynamic>>{};
  
   ...

}

this issue would allow us to implement our own extensions that would, for example, make #107528 doable by the user.

Activity

  1. added
    in triagePresently being triaged by the triage team
    c: new featureNothing broken; request for a new capability
    frameworkflutter/packages/flutter repository. See also f: labels.
    p: material_uimaterial_ui package in flutter/packages
    c: proposalA detailed proposal for a change to Flutter
    and removed
    in triagePresently being triaged by the triage team
    on Sep 1, 2022
  2. added
    P3Issues that are less important to the Flutter project
    on Aug 22, 2025
  3. Mairramer commented on Jan 9, 2026

    @Mairramer
    Contributor

    @Piinks @justinmc I was looking at this and I have a concern. By exposing a getter for fields, we also end up exposing members like restorePending and bucket, which I don’t think should be part of the public API.

    I tried annotating the getter with @protected, but that introduces warnings in other widgets and feels like a code smell to me. Is there a better way to expose this without leaking those internals, or is this not really a problem(maybe only bucket)?

    Perhaps using @internal will solve this..

  4. justinmc commented on Jan 16, 2026

    @justinmc
    Contributor

    Closing this as a duplicate of #107528. I plan to address @Mairramer's comment in #180815.

  5. casvanluijtelaar commented on Jan 19, 2026

    @casvanluijtelaar
    Author

    @justinmc either you accidentally closed this, or listed the wrong duplicate?

  6. danagbemava-nc commented on Jan 20, 2026

    @danagbemava-nc
    Member

    @casvanluijtelaar, wrong duplicate. I fixed it

  7. github-actions commented on Feb 3, 2026

    @github-actions

    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 -v and a minimal reproduction of the issue.

  8. locked as resolved and limited conversation to collaborators on Feb 3, 2026
  9. added a commit that references this issue on Feb 21, 2026
    9c8defe
  10. added a commit that references this issue on Feb 27, 2026
    967206b
  11. added a commit that references this issue on Mar 26, 2026
    e426c6d
  12. added a commit that references this issue on Sep 28, 2026
    1461768
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projectc: new featureNothing broken; request for a new capabilityc: proposalA detailed proposal for a change to Flutterframeworkflutter/packages/flutter repository. See also f: labels.p: material_uimaterial_ui package in flutter/packagesr: duplicateIssue is closed as a duplicate of an existing issueteam-designOwned by Design Languages teamtriaged-designTriaged by Design Languages team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions