Thread by @sebastienlorber

After using hooks for a while, and being familiar with the stale closure problem, I don't really understand why we need to handle closure dependencies, instead of just doing something like the following which always executes latest provided closure (capturing fresh variables)

Coupling the dependencies of the closure and the conditions to trigger effect re-execution does not make much sense to me. For me it's perfectly valid to want to capture some variables in the closure, yet when those variables change we don't necessarily want to re-execute

Note that the above code is already used in major frameworks like Formik by @jaredpalmer and probably some others too. Here's a reference:
github.com/jaredpalmer/fo…
React-redux seems to use something a bit similar here: github.com/reduxjs/react-…

The ESLint rule looks to me only useful to avoid the stale closure problem. Without the stale closure problem (which the trick above solves), you can just focus on crafting the array/conditions for effect re-execution and don't need ESLint for that.

Also this would make it easier to wrap useEffect in userland without the fear to exposing users to stale closure problem, because eslint plugin won't notice missing dependencies for custom hooks.

Here's some code for react-navigation (alpha/v5). To me this is weird to have to ask the user to "useCallback" just to stabilise the closure of useFocusEffect, just to ensure the effect only runs on messageId change.

Not sure to understand why we can't simply use the following instead. For which I don't see the point of using any ESLint rule. I just want the effect to run on messageId change, this is explicit enough for me and there's no "trap"

I may be missing something important (maybe related to concurrent mode?). Has this been discussed somewhere already? Is my trick risky? Then if libs like Formik use it, does it expose all of us to this risk?

@dan_abramov @sebmarkbage or anyone else , would really like to understand this design decision of useEffect, and why we need to handle stale closures in the first place. Any useful link to share I could read?

Thanks

@dan_abramov @sebmarkbage Also this sometimes lead to weird bugs due to api contracts being not totally clear weither they provide stable values or not.

For example in react-navigation, an user reported this code not working as expected (executes too much), because "navigate" function is not stable

@dan_abramov @sebmarkbage I think it would be way simpler if we just expressed the conditions for effect re-execution, ie just re-executed when the boolean change, and ignore when navigate changes (because lib does not guarantee in its contract it does not change anyway)

What bothers me is that somehow as hooks lib authors we now have to think about whether what we return to the user is stable or not, ie safe to use in an effect dependency array without unwanted effect re-executions.

Returning a stable value in v1 and unstable in v2 is a breaking change that might break users apps in nasty ways, and we have to document this too in our api doc, or ask the user to not trust us, and do the memoization work themselves, which is quite error prone and and verbose

Here's a github issue about this where we should rather continue the discussion; github.com/facebook/react…