-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add documentation on updating and resetting form state #144
Conversation
🦋 Changeset detectedLatest commit: c62cc4a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Preview URLsEnv: preview |
|
||
As we learned above, by default the form data passed as `@data` is immutable, and any changes due to the user entering or selecting new data as part of interacting with the form is stored as a separate copy, which we call "dirty" data here (as it deviates from the original data, but is not "persisted" yet). If you change `@data` (either by reassigning a whole new object or updating tracked properties), the form will automatically reflect those changes, i.e. form fields will update their value. | ||
|
||
However, this will _not_ happen for any non-pristine fields, i.e. fields that have new user-entered dirty data, as this would mean irrevocably losing that data. But if that is what you want, you need to explicitly wipe out that dirty data by [resetting the form](./reset). So to keep an existing form in place, but just replace all of its data, you would need to do both reassigning new `@data` and resetting the dirty state! |
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.
Total nit: I like the link to resetting here, but I would like a code snippet on either this page or the reset
page on how to reset.
Reason being, I think folks scan until they see a code sample and likely copy-paste it.
resetForm; | ||
|
||
@action | ||
assignReset(reset) { |
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.
Nit: maybe there should be a comment here that this is only necessary if you want to do something with the reset
callback?
|
||
The following kitchen-sink like example shows all three ways to reset form state: | ||
|
||
- by clicking the native reset button |
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.
nit: I think this can be split into multiple demos.
My concern is that folks with copy-paste this and have all three methods (when perhaps they just need the native reset button).
Could be
- default native reset
- reset "link"
- calling
reset
and a scenario of why this might be desired.
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.
I currently don't have much time, so I decided to merge this as-is, but created this issue to pick up and track your suggestion: #149
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.
🚀
Add the missing docs for #132, #134, #136