Repository navigation
Added a Form widget to manage multiple Input widgets. - #2850
Conversation
There was a problem hiding this comment.
always put a comment in the block of a setState saying what state it is you are changing.
|
OK, I uploaded a new iteration. Main changes:
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. |
There was a problem hiding this comment.
Should I name this back to _FormFieldState? It doesn't derive from State, but it is used only as a member var of InputState. And it does represent the 'state' of the form field...
There was a problem hiding this comment.
if you don't like _FormFieldData, maybe _FormFieldValue? By convention, if the class ends with State that means it inherits from State<T>.
|
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 |
No description provided.