OK, I uploaded a new iteration. Main changes:

• No more Maps. InputState holds onto the _FormFieldData (previously _FormFieldState) rather than shoving it in a Map on the _FormState.
• No more form IDs. I replaced them with generic setters, which lets the user can store the Form data anyway they wish.

I will move Form and all related classes to a separate file next (except _FormFieldData, which is specific to Input). I kept it as-is so you could see the changes with the previous version.

LGTM

Hopefully before too long we can begin using tear-offs for the setter functions.

This needs tests.

If I understood the original purpose of Form correctly, it was to make sure that you didn't need to store the state of form fields in the object whose build function creates the Inputs, even if the build function changed its structure each frame. I don't think this feature exists any more in the patch as it stands today.

The original purpose of Form was so client code (e.g. text_field_demo.dart) didn't need to store a list of InputValues. This way, it stores the form data in a way that is natural to the client (struct PersonData). The InputValue book-keeping is handled by the Form class.

But the reason the client code kept the InputValues was so that if the build changed structure, the selection wouldn't be blown away. Isn't that lost with this change?

No, without a Form, the client code needs to keep InputValues no matter what. That's the only way the input value will change at all (Input doesn't remember what was typed).

I don't think the form data or selection will be blown away - as long as the Inputs have keys. That will ensure they have the same InputState, right? But even if not, that was not my original goal.

Fair enough. I'll file a bug to worry about that problem later.

I've added tests in form_test.dart.

LGTM