-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Added a Form widget to manage multiple Input widgets. #2850
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.