Major gotcha with react/exhaustive-deps

🐛 Bug report / Feature request

Build forms in React, without the tears 😭

Today, I cried…

Current Behavior

Consider the following contrived example. The ESLint rule react/exhaustive-deps immediately complains that formik needs to be in deps. Makes sense, why not? Ouch! Such callback will be recreated on every little change because useFormikContext always returns a new object.

const formik = useFormikContext()
const setField = React.useCallback(field, value => {
  formik.setFieldValue(field, value)
  formik.setFieldTouched(field, true)
}, [formik])

The callback alone wouldn’t be too bad. But then comes useEffect into play and things get very bad. The ESLint will once again suggest adding callback setField to deps. Originally the effect that is supposed to be executed once (on mount) is now executed on every little change.

React.useEffect(() => {
  readFieldMemory('name').then(memory => {
    setField('name', memory)
  })
}, [setField])

Lines of thinking here are like: “I have it wrapped in the callback, it’s safe to have effect depend on it, right? Damn…”

Expected behavior

I am aware I can disable ESLint for that particular line and avoid adding that dependency there. That’s not the point. Anyone can get burned by it because it’s a good assumption it will work just fine.

Reproducible example

https://codesandbox.io/s/happy-dubinsky-91lhc?eslint=1&expanddevtools=1&module=%2Fsrc%2FFormMemory.jsx

Notice it grows geometrically for some reason and might kill your browser tab. But there is a button to actually start it, so don’t worry to open and check the code first.

Suggested solution(s)

This is really tricky. One side of a problem is that recreating a new object will allow Context to re-render interested parties. With stable reference, no render would happen.

So I am thinking something along the lines of splitting state and api object and providing two hooks for accessing each. The api object can have a stable reference while state can still cause necessary re-render. And ESLint suggestions won’t be a problem anymore.

[jaredpalmer]

I think I need to think thru this more

[johnrom]

I don’t have a chance to confirm this theory works right now, but if setFieldValue and setFieldTouched are useCallback’d correctly, it should help to depend on those callbacks instead.

const { setFieldValue, setFieldTouched } = useFormikContext()
const setField = React.useCallback((field, value) => {
  setFieldValue(field, value)
  setFieldTouched(field, true)
}, [setFieldValue, setFieldTouched])

I am not against the idea of splitting formikContext into formik and formikState where formikState is a snapshot and formik.currentState would be the live state. I think this would be super helpful for async operations.