changing initialValues must overwrite current field values by default

[kromit]

Since 5.1.2 the the known behavior of initialValues was changed/broken I would like to know a way to reuse an existing form.

There are at least two use cases when the form values must be overwritten by initialValues:

1. The form is rendered with disabled input fields and loading indicator during async loading. Current empty values must be overwritted by initialValues applied from async loaded redux state.
2. The form is displayed along with an item list. Selection from the list changes initialValues and should overwrite any user input.

The "Initializing From State" can be extended with a second load button with a different data set to demonstrate the expected behavior.

On the side note: I still do not get why such a breaking change was introduced in a bugfix instead of a major release since every version until 5.1.2 was working that way. I've looked into #370 and #832. and I must say that there is no such thing like the "right" behavior. There is only a "least wrong" behavior since the majority of people who are satisfied with currently working behavior do not create/comment on tickets about how satisfied there are, but they also must be taken into account when changing things.

[erikras]

There is only a "least wrong" behavior since the majority of people who are satisfied with currently working behavior do not create/comment on tickets about how satisfied there are, but they also must be taken into account when changing things.

👍 Excellent point.

[aight8]

I have exactly the same use case. Happy to see that this way comes back to set new init values. 👍

[erikras]

Okay, so it'll have to be a config param. Check out v5.2.1. You guys won the "default" side of the issue, and those in #832 will have to provide a config parameter to achieve their desired behavior.

[kromit]

@erikras Oh wow. THAT was fast! Many thanks for what you are doing.

[kpdecker]

Hopefully this doesn't sound too annoyed, but all of the users that deployed the 5.1.3 behavior just got the same breaking change that is complained about in this bug. No real issues with the change but it would be nice if we could follow semver for these sorts of things (I know it's hard, https://github.com/wycats/handlebars.js was a constant stream of complaints like mine when it was under active development)

[kpdecker]

Also would like to add a thank you to @erikras, you are amazingly responsive on this project, so I hope the above comment comes off as constructive and not just complaining :)

[aight8]

Are there plans to use this logic in v6 too, or should the user use the initialize action only for this case?

[erikras]

@kpdecker Yes, I do try to follow semver, and I feel bad about breaking it with these two updates, hence my scramble to unbreak the change. Since I've already started releasing alphas of the next major version, semver has put me in an awkward spot. Constructive criticism accepted. :-)

@aight8 I plan on v6 behaving as close to v5 as possible when it is released, so yes.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.