Closed oyeanuj closed 6 years ago
Yeah, it would be almost trivial to have something like this API:
<Form model="user" submitOn="change">
...
</Form>
(or 'blur'
or 'submit'
(default)), but of course it would submit the entire form.
The tricky part is the whole only-submit-changed-field(s) part. I think there was a previous issue: #409 that discussed this.
@davidkpiano It seems like in #409, the complexity was needing to check what was changed or not in the whole form? The use-case in this issue whereas seems to be a much simplified version of that usecase since it seems logical only to check if that field is dirty (or not pristine).
That would not only make 'only-submit-changed-field' logic much simpler, but atleast to me, more intuitive (than submitting the whole form when auto-saving on each field).
@oyeanuj That makes a lot of sense; I didn't even think of that!
Bikeshedding time:
<Form
model="user"
submitFilter={field => !field.pristine}
/>
Above is an initial (and probably terrible) idea for the API. What would an ideal submit-only-dirty API look like to you?
@davidkpiano That's interesting. I was thinking of a couple of different approaches.
onSubmit
the field that was active and is dirty. By definition, that would only be field at a time.
It might be cleaner for the library to do so rather than the user, lets say, if the autoSave
prop on the form is set to true
.<Form model="user" autoSave />
//the onSubmit function would still receive the model
//but only with the field which triggered the action
onChangeSubmit
prop to each field. This might make it a little bit more useful to other usecases than autosaving forms
<Form model="user" autoSave>
<Control.text model="user.firstName" onChangeSubmit={this.updateFirstName} />
</Form>
Another thing to consider if going this route, is if the library should provide a debounce
prop to use with the onChange
or if that should be somehow be done in userland - maybe as a wrapper around each control?
And finally, the caveat: I haven't used the library yet(!), so not sure if breaks some assumptions around the model
concept as you might have envisioned. Sorry about that!
Thoughts?
@davidkpiano Just checking here, to see if you've had the chance to think about the two options above? Or if you had any other ideas for the API?
is this still pending?
@iBasit this is best solved in user-land. You have full access to the values via the Redux store, so you can implement auto-saving yourself.
@davidkpiano Hm.. I was hoping to see this in v2. But I see your point about userland but it ends up being a lot of duplicating logic trying to implement something like onChangeSubmit
which only submits that field.
I feel like if the library offers API similar to what we discussed above, it might make it much cleaner to implement the rest in userland.
Curious about your thoughts on providing API for those solutions - or are those also best solved in userland?
sorry off the topic, but is there a method for onChangeSubmit
? (I'm looking for it lol)
Hi @davidkpiano! As per our conversation on Discord, here is the feature request to be able to support auto-saving forms.
Usecase: Creating an auto-saving form, where values are saved as the user enters them. This, in most cases, will imply that the changes are saved (and/or validated server-side)
onChange
, though probably debounced. In some cases,onBlur
can work but it is not always the optimum user-experience (for example, choosing a username)Users might choose to submit in one of two manners - submit the entire form, or submit just that field. This is likely to happen when it is a heavier or a longer form.
FWIW, I hacked together a solution using Redux-Form and React-Debounce-Input that can be found here - https://gist.github.com/oyeanuj/2f69ebe1004e2ff47d7550d957bf05cf with the basic overview in the file TheAutoSavingForm.md in that gist.
Thank you!