Skip to content
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

initial data issue #2

Open
MikeSha opened this issue Aug 11, 2018 · 1 comment
Open

initial data issue #2

MikeSha opened this issue Aug 11, 2018 · 1 comment

Comments

@MikeSha
Copy link
Contributor

MikeSha commented Aug 11, 2018

Hey @ansmith ,
I have a question.

https://github.com/kentik/mobx-form/blob/master/src/components/Form.js#L40

I guess I understand the purpose of this condition. But I think it should be optional, because as for me it's confusing a little, when form is submitted and all fields go to their initial values.
Of course, it's not necessary to use this exact Form component and it's possible to write another one.
So, finally the question :) What if this condition will be removed? :)

I hope you understand my point, English isn't my native :)

@ansmith
Copy link
Collaborator

ansmith commented Aug 15, 2018

Sorry to take so long in getting back, I was away on vacation this past week.

So generally the purpose here is to prevent the form reinitializing (and washing out dirty fields) just due to standard React re-renders that may occur outside - namely, further up in the component tree. I think it's a sound approach, but we can talk more about it and I'll leave this open for that purpose. It's possible that your submission process is a little different. For us, when we submit the form, the values field isn't updated until those dirty values are persisted. So (assuming it succeeds) the form now reflects the current state in the persistence tier and it being pristine and non-dirty is appropriate. Based on what you're saying that's either happening prior to it being persisted (not great) or it's not happening at all and your form reverts back to previous data (very bad). So it's very possible the issue lies in your persistence/state mgmt code outside of this lib. Let me know if I'm not understanding things quite right.

That being said, Form (and Field for that matter) are fairly opinionated components and I think it will be pretty common to want to create your own forked versions of these. If you go this route, I'm happy to help answer questions you may have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants