Adding notifyOnChange as a side effect to succesful handleChange

[rohanBagchi]

Description

This PR adds a side-effect to formik's handleChange which can be used to react to any update to formik form state.
The effect is similar to formik-effect except built into formik itself without the need to install any additional library or retrofitting formik's validate hook to perform the callback.

Usage

In my project I had to broadcast a form dirty signal whenever user begins typing on it. This I implemented by triggering said signal from validate.
While this works for my use case, I cannot now make the form validate on blur as this would delay triggering of dirty signal.

If this change gets accepted, the users can add their own callback to react to formik state update like this:

<Formik
    {...}
    notifyOnChange={this.notifyOnChange}
>
    {...}
</Formik>

[tristanmarsh]

Yes please!

[rohanBagchi]

@jaredpalmer can we merge this? or if you have any other solution in mind, please revert back.

[animify]

Need this! 👍

[ducdev]

Need something like this. Please consider merging.

[ghost]

@jaredpalmer after jumping around a few issues referencing the same problem I realized there are a lot of people facing it. The form level onChange seems such a common use case that with little effort would make formik an even better form library... however the latest threads seem ignored by the project maintainers. Please, consider responding (even if the answer is won't do) to the latest comments on these threads:
#485
#271
#401
#1397
I'm trying to solve this problem on my project on day one of adopting formik (which I liked a lot) and after reading all those threads I still don't know what should I do. Having to install a 3rd party package to solve such a common use case doesn't feel good to me.

[ebrearley]

@jaredpalmer after jumping around a few issues referencing the same problem I realized there are a lot of people facing it. The form level onChange seems such a common use case that with little effort would make formik an even better form library... however the latest threads seem ignored by the project maintainers. Please, consider responding (even if the answer is won't do) to the latest comments on these threads:
#485
#271
#401
#1397
I'm trying to solve this problem on my project on day one of adopting formik (which I liked a lot) and after reading all those threads I still don't know what should I do. Having to install a 3rd party package to solve such a common use case doesn't feel good to me.

Maybe this PR isn't required since it's possible to achieve with the existing API. See my comment in #271 (comment)

[jaredpalmer]

This is possible with the existing API. There is no need for this addition.

[serusko]

hi @jaredpalmer culd you please add some ref to existing solution, i think a lot of people end here with some googleing :) so we could prevent reopens or duplicates :)

[tom-wagner]

Boo!!! no fun!!!

[Cyclodex]

For me, this article here helped: https://plainenglish.io/blog/how-to-listen-to-formik-onchange-event-in-react

[wchargin]

An important advantage of the approach proposed in this PR (and the other linked threads), compared to the useEffect-based "Formik observer" approaches, is that the change notification takes effect in the same render cycle.

When you use a useEffect to extract the change event, the flow is:

1. User types in a text field, causing a React onChange event.
2. onChange handler calls into Formik handleChange, which updates state.
3. Component re-renders with new state, and the useEffect dependency changes.
4. After rendering, the useEffect callback is called, and itself calls some React state setter (e.g., to smuggle the Formik state out to a different component to render a preview).
5. Affected components re-render again, with the same Formik state but new state that was changed due to the Formik observer.

This is unnecessary! It creates visible lag and jank, in addition to useless renders. The React docs "You Might Not Need an Effect" are all about how to remove instances of this general pattern of using effects to observe changes and call state setters. Effects are for subscribing to external stores or managing event listeners on imperative components, not communicating React state around.

If Formik exposed an onChange handler, as proposed in this PR, this would all be done in a single render cycle. I am actually not aware of a way to achieve that with the existing Formik APIs.