react: useCallback() invalidates too often in practice
This is related to https://github.com/facebook/react/issues/14092, https://github.com/facebook/react/issues/14066, https://github.com/reactjs/rfcs/issues/83, and some other issues.
The problem is that we often want to avoid invalidating a callback (e.g. to preserve shallow equality below or to avoid re-subscriptions in the effects). But if it depends on props or state, it’s likely it’ll invalidate too often. See https://github.com/facebook/react/issues/14092#issuecomment-435907249 for current workarounds.
useReducer
doesn’t suffer from this because the reducer is evaluated directly in the render phase. @sebmarkbage had an idea about giving useCallback
similar semantics but it’ll likely require complex implementation work. Seems like we’d have to do something like this though.
I’m filing this just to acknowledge the issue exists, and to track further work on this.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 170
- Comments: 115 (24 by maintainers)
@sokra An alternate would be:
This doesn’t require the args like yours has. But again, you can’t call this in the render phase and the use of mutation is dicey for concurrent.
We’ve submitted a proposal to solve this. Would appreciate your input!
https://github.com/reactjs/rfcs/pull/220
the rfc sounds nice. In almost any react app, I end up using a
useLatest
hook to ref-ify non-reactive values I only need in response to some event. I wonder if all usages ofuseLatest
are related to event handling and hence covered by the proposed hook for creating event handlers.On a different note, the name
useEvent
confused me in the beginning and I see many people are also talking about it. 🟢useState
=> returns state (and setter) 🟢useRef
=> returns ref 🟢useCallback
=> returns callback 🟢useMemo
=> returns memorized value 🔴useEvent
=> returns event handlerI get that having a short name is nice, but confusing “event” and “event handler” is a much more considerable drawback IMO. I think
useEventHandler
oruseHandler
(if having a short name is deemed very important) are better choices.Stuff like this is why Vue or Angular are still alive.
On Sat, Jan 28, 2023, 7:57 AM ZZYZX @.***> wrote:
The
useEvent
proposal definitely goes in the right direction, as the misuse ofuseCallback
is something we’ve all seen countless times across teams and organizations.I do want to express some strong concerns around the naming as
useEvent
could potentially be very confusing for less experienced engineers or those who are coming to React from other frameworks. The dangerous naming correlation to DOM events makes it quite misleading at first glance and seems to hide its true purpose.I much prefer
useStableCallback
as someone else suggested, oruseHandler
as I feel it makes it easier to document and explain its usage moving forward.useCallback
lets you memoize the callback to avoid a different function being passed down every time. But you have to specify everything it depends on in the second array argument. If it’s something from props or state, your callback might get invalidated too often.useReducer
doesn’t suffer from this issue. Thedispatch
function it gives you will stay the same between re-renders even if the reducer itself closes over props and state. This works because the reducer runs during the next render (and thus has natural ability to read props and state). It would be nice ifuseCallback
could also do something like this but it’s not clear how.In concurrent mode (not yet released), it would “remember” the last rendered version, which isn’t great if we render different work-in-progress priorities. So it’s not “async safe”.
@sophiebits That’s clever and would have none of the problems with args, etc. It even doesn’t require a dependencies list.
One nitpick:
return useCallback((...args) => (0, ref.current)(...args), []);
to pass along i. e.event
argument.Late to the party here, but after scanning the above thread- there is another potential problem in the
useEventCallback
example and other example uses ofuseLayoutEffect
above:It’s very, very different behaviour
With a ES6 class I can pass onChange={this.handleChange} to the child component and it does not redraw every time (because it sends the same handleChange method every time)
It’s frustrating that dispatch works independent of state (I mean the dispatch method does not change even if the underlying state does) but useCallback does not (if your callback needs to do something with state that is)
I see a lot of code where the whole form redraws when the use types into a field
A lot of devs don’t understand this until users complain ‘it’s slow’
Would be nice if second argument of
useCallback
was injected as dependencies to callback function.Tbh this is making me super skeptical of concurrent mode, given that function memoization is the number one tedious thing I deal with daily in React since hooks were introduced (everything else about hooks being fantastic) and concurrent mode wouldn’t benefit me personally right now AFAIK, yet sounds quite dangerous to use.
Gentlemen:
useGranularCallback
fromnpm i granular-hooks
BTW, I use their useGranularEffect() a lot because I don’t want useEffect style triggering when only certain vars should trigger updates. It takes two lists of arguments, primary and secondary deps as arrays. primary deps trigger calling the hook or changing the callback, secondaries don’t.Workarounds above (especially relying more on
useReducer
) seem sufficient for most cases. There are cases when they’re not, but we’ll likely revisit this again in a few months.I recently made a duplicate issue and was asked to check this one. What I proposed there was very similar to @sophiebits’ approach, but still looks a bit simpler to me:
This way it is guaranteed to update where the hook is called since it does not directly use any side effect and instead it only updates a reference. It seems to me that it should be callable during the render phase and should not be dicey with concurrent mode (unless references don’t meet these two conditions). Wouldn’t this approach be a little better or am I missing something?
One more argument against the “useEvent” naming. The following statement derived from the RFC doesn’t make sense in English:
How can an event throw? How can an event be called? An event is something that happens. Sometimes we say “an event” as a shorthand to “an event object” that not only mentions what happened, but also describes the details about what happened.
But it feels unintuitive to use “an event” as a shorthand for “an event handler function” that processes what happened during an event.
While writing the above, I think I understood one way of thinking where these can be equivalent: if we treat an event as something not instantaneous that has duration (which is not how events are usually treated in software engineering), and then treat the side effects as an unseparable part of an event, then the function that processes the event is the part of the event, hence “using an event” makes some sense.
It ensures that the receiver (this value) of the function isn’t ref.
Concurrent mode can produce two different representations of a component (the first one is that commited to the dom and the second one is that in memory). This representations should behaves accordingly with their props and state.
useEventCallback
by @sophiebits mutatesref.current
after all dom mutations is completed, so thecurrent
(in-memory) component can’t use the newest callback until the commit is done.@muqg proposal mutate the callback on each render, so the
commited
component will lose the reference to theold
callback.The point of my proposal in the passing a separated callback reference, that will changes in commit phase, to the dom, while the in-memory (not commited) representation of a component can use the latest version of that callback.
In this case, you wont pass down the
handler
to other components because it always changes. You will pass thecallback
, but will face again the concurrent mode problem.@muqg In concurrent mode, last render doesn’t necessarily mean “latest committed state”. So a low-priority render with new props or state would overwrite a reference used by current event handler.
Drawbacks:
It’s easy to forget the arguments list, which would result in hard to find bugs. In dev mode it would make sense to check fn.length for the correct length.
It’s still possible to forget arguments in the dependencies array, but this applies to other hooks too.
Definitely agree with @floroz regarding the naming and would prefer something like
useStableCallback
.Had a use case for @sophiebits proposed
useEventCallback
(https://github.com/facebook/react/issues/14099#issuecomment-440013892). The problem withuseLayoutEffect
is that it issues warnings when server side rendering. You can trick React by switching touseEffect
based on the environment (typeof window
) but this won’t work if the SSR API is called in the browser (with-apollo
).Wouldn’t
useImperativeHandle
work as well?Edit: WARNING This means that the callback cannot be called safely in the effect cleanup phase. When unmounting the ref will be nulled before the cleanup phase.
@gaearon then do you plan to release
useCallback
with the first release of the hooks? After all it is confusing (current issue) and it is not a primitive hook (is equivalent touseMemo(() => fn, inputs)
)@carlosagsmendes you can probably use the workaround
useEventCallback
from above. You can see your example with it hereI put the
useEventCallback
(with couple changes) here again:I think with @sophiebits’ approach this will work. The latest function is always copied into the ref and only a trampoline function is returned. This will make sure that the latest function is called, which has the latest state in context.
to be honest, I’m not sure why the implementation of the useEvent has to be so complicated, why not just this?
below is the typescript version
with this implementation, there is no such thing as when will the current is switched, because it will be switched every single time, and it can be used in rendering as well
@nikparo Nothing to be sorry for, I think that’s important and that proves my point. We use programming languages and naming conventions to communicate, but this particular (useEvent) naming introduces a lot of space for ambiguity. By the way, “event function” also doesn’t make a lot of sense in the context of “an event” as a marker for a point in time when something happened instantaneously.
EDIT: “An event handler function” (or, more grammatically correct “an event-handling function”) from my point of view makes more sense than “an event function” because the main keyword here is “handler”/“handling”, a function that that “handles” the event. English doesn’t make this easy because whether a word is a noun or an adjective depends on its position in a sequence of words.
@sokra With this you will not be able to access to state and props updates inside a callback.
So dependencies are required.
Given that the ‘useEvent’ hook has gone the way of the doodoo what are the plans to solve this issue?
I was a big fan of the ‘useEvent’ hook - and end up having to copy my own implementation in every other project (something like use-event-callback or the one @HansBrende mentioned in that issue).
To bring this issue to a final close why not encourage a simply “hook recipe” on the documentation?
Something like:
I understand that the team is currently investigating other options for the ‘rendering optimizations are cumbersome to type’ problem- but us every day developers don’t have access to these tools.
Indeed, should they be released we might not be able to use them because we’re stuck on an old version of React for some reason or another.
This gist is written in typescript and allows you to get several states at once.
The RFC states that the event function created by
useEvent
will throw if called during render, which is what you did with your curried handler.As a long time user of react, I also agree.
useEvent
makes me assume we are using an emitter and i would avoid handler for the same reason as it implies action in response to an emitted event. I like your suggestion ofuseStableCallback
overuseEvent
@zheeeng I’m not sure what’s the benefit of even using
useCallback
in your case.handleChangeValueByIndex(i)
will always return a new function even though thehandleChangeValueByIndex
itself is memoized.Having said that, there definitely are cases where
useCallback
should still be used even after introducinguseEvent
. One example is memoized components that use render props:Here, if
List
is memoized,renderItem
reference has to change along withitems
, otherwise the changes toitems
won’t be reflected on screenI wrote a hook that achieves exactly the same some time ago.
Would you please have a look, @gaearon? It might be every so slightly more efficient than yours, as it uses two hooks rather than three.
If you’re interested, I also tried to start a discussion here.
Adding more React specific concepts like
useEvent
seem troublesome on a first glance considering it’s more of Reactisms that kinda fight with the underlaying JS language principles. That being said, I don’t see a better solution for this specific issue at the moment, RFC seems very well thought through.FYI: My snippet of useImperativeHandle solution https://github.com/facebook/react/issues/14099#issuecomment-569044797 is like this (it is TypeScript, remove type annotations for JS):
That doesn’t sound right. Our docs list examples of using the ref for non-React values. The key is when to update the
.current
property. React updates this property during the “commit phase” (when effects are run) and we suggest you do the same1 to avoid problems like the one I mentioned above.1 The one exception to this is using a ref to lazily initialize a value. This is only safe because it’s idempotent.
@Volune
Current
useCallback
is quite helpful with render props pattern. One example isList
fromreact-virtualized
. It’s aPureComponent
, so you can pass a memoizedrowRenderer
function to prevent rerenders. But if yourrowRenderer
doesn’t invalidate when its deps change (e.g. if it’s an instance property on a class component), you have to pass all those deps asList
props to trigger rerenders when they’re actually needed.Example on codesandbox: https://codesandbox.io/embed/staging-snow-sgh7v Note how I have to pass an extra
value
property toList
to fix the class example whileuseCallback
works as is because it invalidates whenever it would produce a different output.@muqg @strayiker BTW this is why there’s no much sense in trying to make
useEventCallback
work in the render phase: If a child uses your callback to render something, you most likely want it to invalidate as often as its deps change. Also, this is whyuseEventCallback
is a really good name. Basically, it says “only use me for event handlers”.@vzaidman
The solution by @sophiebits does the same without a need for stating any deps at all. The callback from
ref.current
always has a fresh closure. So the usage looks like thisAren’t class components also exposed to this? Seems React does the same thing to Class Components (mutating props in render phase)
https://github.com/facebook/react/blob/4c5698400f04bbc6d0b4bd766b0993d0bcb37609/packages/react-reconciler/src/ReactFiberClassComponent.js#L1042-L1045
also seems the committed and work-in-progress fibers share the same class instance
https://github.com/facebook/react/blob/4c5698400f04bbc6d0b4bd766b0993d0bcb37609/packages/react-reconciler/src/ReactFiber.js#L413
If React assigns pending props to
instance.props
in the render phase but the render work is interrupted for some reason,this.props
will reflect the props of the WIP (outside of render phase) since both share the same instance. If an event handler fires in between and accessesthis.props
it’ll see the WIP props while it should rather seethe committed props.I assume the solution is to switch
this.props
between phases, maybe this is already done but I couldn’t trace it in the sources so just wanted to make sure this is handled.@sebmarkbage I tried the approach above of using the
oldData
argument, but it didn’t help me to avoid re-renders of the children components (that’s why I was using useCallback)So I tried using useReducer and use dispatch inside the useCallback but all the children are still re-rendering.
Moreover, I’m passing the state to a callback after changing it, and it is always the previous state (off by one).
Can someone take a look and let me know what the recommended approach is?
Thanks in advance!
How/why is it that variables are dereferenced within
useEffect
?Whether or not the effect is called again based on changes to state/reducer/etc (
useEffect
’s second param), shouldn’t have any implication on those variable’s references withinuseEffect
, right?This behavior seems unexpected and having to leverage “escape hatches” just feels broken to me.
I don’t think there is a point in saving the “current”, if you want to call it during rendering, just save it in advance out of the hook:
I personally don’t see any benefits of the current
useCallback
implementation over the proposeduseEventCallback
, will it become the new implementation? Also, can it warn when the callback is called during render in development mode?@Moranilt
The main idea is to memoize a callback, which is passed to another component. In your example you’re trying to memoize a callback, which is passed into
<input />
. But there is no point to do it, cause,<input />
does not have any instruments to use that memoized callback.So, in your example you could memoize set*** callback. But in your case they are memoized already)
But, I have a fix for your example:
Right now,
<Input />
will be rerendered in case of thevalue
prop changing.@BirdTho They are being passed to the hook* (not callback), sure, but they are only updated when the primary deps are updated. There is no magic connection between the values in the closure and the values in the dependency array. In other words, the callback closure remains stale until the primary deps change.
But this is getting off topic, so if you don’t believe me I suggest you simply test it yourself with and without the so called secondary deps.
@mariusbrataas Updating a ref during render is an unsafe side effect.
I was aware of that. I actually meant “before or after committing children”. Sorry for the confusion.
Agree.
Another solution, that would work better, I think:
Of course, that’s bad because it’s using unsafe API (
React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
). Perhaps something likeuseConcurrentModeSafeRef()
could be added to React itself.Might this approach work fine when combined with useConcurrentModeSafeRef()?
Hoping there will be some solution to this in React 18.
What if we had some kind of ref hook that safely keeps track of the last commited value on any given render thread?
Maybe it could have a
current
property with getters/setters just likeuseRef
; I just usedsetCurrent
/getCurrent
in my example to illustrate that magic would be happening under the hood.@Hypnosphi the problem you describe is a general useEffect problem (how to write effects with dependencies that don’t need to trigger the effect), it is not specific to the the useCallback solution i described. there are number of approaches you can take to solve prop dependencies in effects.
i suggest taking a look here: https://overreacted.io/a-complete-guide-to-useeffect/#why-usereducer-is-the-cheat-mode-of-hooks
there is also a custom hook named “usePrevious”, you can use it to check if a specific dependency changed on useEffect. im not sure how much of a best practice it is.
here is one solution:
you can use props inside reducers if you put the reducer function inside the component (which you shouldn’t do by default, but you can). note that logReport does not change when props.name changes, but only when the user clicks.
@liorJuice how would you use props in side effects with this approach?
I found that you can use useReducer to mitigate this effectively. the bit that was hard to swallow is when i needed side effects to happen in the callback.
Side effects cant happen in the reducer as it is being called with past actions a lot, on re renders, for some reason. so the reducer must be pure (state, action) => resultState, with no side effects.
The solution was to use useEffect that listen to changes in the reduced state (resultState), to initiate side effects, which suddenly seemed obvious. 😅
for example, this code:
which will create a very problematic callback, could be perfectly replaced with:
which will have the same effect but with handler that will persist through the entire lifetime of the component.
i think this is the most complete solution to the useCallback problem. @gaearon can you confirm?
@mariusGundersen
setCopy
is guaranteed to remain the same through component’s lifetime, whilecreateCopy
changes each time whenvalue
doesThis line in your above example could cause problems:
Since you’re mutating the ref during render- and renders can be async- you can end up mutating it prematurely (so that a previously-rendered thing calls the
callback
and gets a not-yet-renderedparams
value.To avoid this, you would want to update the ref in a layout effect (
useLayoutEffect
) although this has its own drawbacks (see this comment).Edit for clarity.
@arnotes Looks like you are updating your ref during the render phase, i.e. before it has been commited, rather than in a
useEffect
call. To quote @gaearon :Afaik the drawback with updating the ref in a
useEffect
is mainly that you then can’t use it during the render.I found myself doing this often:
Does that have any drawbacks besides unnecessary effects?