Replies: 1 comment 4 replies
-
v3 will use a new state system that would allow something like this (API is tentative): const formikRef = useRef(null);
// (selector, initialValue)
// you'd have to memoize or use a constant callback
const [dirty, subscription] = useFormikSubscription(state => state.dirty, undefined);
useEffect(() => {
return formikRef.current?.subscribe(subscription);
}
return <Formik innerRef={formikRef} />; The initial value is not available until the ref has been created after the initial tree has been built, so you'd have to determine what it is using outside knowledge, or use a temporary value you can check against for special cases. Before it lands, there's not a supported way to access updates to state from the outside world. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I like that you can have different components access the Formik form properties using
useFormikContext
. In many cases this is the way to go. I had a situation where I had this global app bar that was higher up in my DOM hierarchy that needed to contain submit/reset buttons which also needed to be disabled when the form was not dirty. This app bar could not live within the<Formik>
element so I couldn't useuseFormikContext
.My app also has many pages of forms and the app bar's contents change to correspond to the current sub view route so the reset/submit can end up talking to totally different Formik form instances from page to page. I tried using a portal to instead have my app bar render within Formik but it had bad layout side effects where the height reserved for the app bar wasn't reliable, nor was my fancy hide/show appbar on-scroll feature.
Here's what I came up with, is there a better approach? I couldn't find one:
https://stackoverflow.com/a/68810561/756177
Thanks,
Andrew
Beta Was this translation helpful? Give feedback.
All reactions