Ensure that validated values object is same object that is saved to state (+ Reduce number of actions)

[MaximSagan]

The problem

The main problem I set out to solve with this PR was the creation of two different values objects on every setFieldValue call.
Namely, https://github.com/formium/formik/blob/c583eccc10378cbfc476c4cff3077e65b8e847ef/packages/formik/src/Formik.tsx#L79 and
https://github.com/formium/formik/blob/c583eccc10378cbfc476c4cff3077e65b8e847ef/packages/formik/src/Formik.tsx#L597
The former is used to update the state.values property, and the latter is used to validate the form (and ultimately update the state.errors object). The problem comes when the user wants to perform any kind of memoization of complex validation results, the values object that gets validated initially on setFieldValue is lost (a different object is saved to state) so it cannot be used for comparison to determine whether to re-run validation.

What I've done

To solve the problem stated above, on setFieldValue, I create a single new values object, and this object is used to both update state and in validation. With this change, the distinction between the SET_FIELD_VALUE action and the SET_VALUES action was not needed, so I removed the SET_FIELD_VALUE action.

For consistency, I also removed SET_FIELD_TOUCHED and SET_FIELD_ERROR actions.

[jaredpalmer]

@johnrom i think this is fine?

[johnrom]

I haven't tested, but based on a code review this looks like a nice performance enhancement. the only downside is that validations can now modify the values object. but so can any other part of the code, so I don't think it matters too much.

[MaximSagan]

@johnrom

the only downside is that validations can now modify the values object. but so can any other part of the code, so I don't think it matters too much.

This is true, but it's worth noting that validation was already able to modify (mutate) any child-objects/arrays of values that were not directly created by the setIn() call.

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days

[vercel]

@MaximSagan is attempting to deploy a commit to the Formium Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days

[johnrom]

If I understand correctly, this isn't actually the same because the dispatch has the actual latest state as serialized by the reducer, whereas the state accessible to the setFieldValues and other functions could be stale, especially in the case of calling it multiple times per render.

This will be possible in #3089 because we provide getState() for exactly this purpose. @MaximSagan I think you should rebase this off of that branch and it can be merged once that is merged.

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days