All topics
Performanceintermediate

Avoiding Anonymous Functions and Objects in Render (Deep Dive)

Understand precisely when inline functions and object literals in JSX are harmless versus when they measurably hurt performance.

It's extremely common to see advice to 'never use inline arrow functions in JSX,' but this is an oversimplification — inline functions and object literals are only a performance concern when their changing reference actually defeats a downstream optimization, such as a child wrapped in React.memo or a dependency array relying on reference stability. In a component with no memoized children and no such dependency arrays, a fresh inline function every render costs a trivial allocation that's rarely worth worrying about.

It's like reusing the exact same key (a stable reference) so a lock (React.memo's comparison) recognizes it and doesn't bother rekeying the whole door each time — but if there's no lock at all on that particular door (no memoized consumer), cutting a fresh identical-looking key every time costs you nothing extra to worry about.

Key Concepts

1
The nuanced rule is: inline literals matter when they're passed to a React.memo-wrapped child (defeating its shallow prop comparison) or included in another hook's dependency array where a changing reference triggers unwanted re-execution (like an effect re-running every render because its dependency is a new object each time). In those specific cases, useCallback/useMemo genuinely help by stabilizing the reference so the downstream comparison can actually skip work. </br>Blanket-applying useCallback to every handler 'just in case' adds its own small overhead (storing the previous dependencies and function, comparing them each render) and adds visual noise to the code without a clear beneficiary — the linter rule react-hooks/exhaustive-deps doesn't require this by itself, it only flags genuinely missing dependencies.
React.memouseCallbackuseMemoreact-hooks/exhaustive-deps
2
Interviewers use this topic to separate candidates parroting 'always memoize everything' advice from those who reason about it correctly — a strong answer identifies the specific downstream consumer (a memoized component, an effect's dependency array) that a stabilized reference is meant to serve, and recognizes that without such a consumer, the optimization has no effect to point to.