useSelector re-renders on every dispatch: how to pinpoint the selector causing it

Attribution workflow for React-Redux v8

Confirmed fact: useSelector re-renders a component when the selector’s return value is not === to the previous value. Likely explanation in your case is reference churn from derived objects and/or inline selector definitions, not a parent or context re-render.

1. Correlate a dispatch to a component render

• Open React DevTools Profiler, start recording, dispatch the action in Redux DevTools, stop recording.
• In the Profiler flamegraph, note which components render for that single dispatch. If a component renders but its props are unchanged, keep it as a suspect.
• In Redux DevTools use Jump to action to replay the same action and confirm the render set is repeatable.

2. Confirm selector reference churn vs parent/context

• Temporarily wrap the suspect component with a parent that never re-renders. If it still renders on every dispatch, the cause is internal to useSelector.
• Log selector identity and result reference inside the selector: console.log('sel ref', selector, 'result ref', result). A new result object on every dispatch while state slice is unchanged indicates reference churn.

3. Classify the selector

• Inline selector defined in component body: new function each render. This forces useSelector to run each time and defeats memoization. Move the selector out or memoize the function with useCallback.
• Selector returns a derived object/array, e.g. state.items.map(...). Reference will change even if inputs are stable.

4. Choose shallowEqual vs createSelector

shallowEqual suffices when the selector returns a flat slice from state that is itself stable by reference, such as a primitive or an object that Redux Toolkit Immer returns unchanged between unrelated updates. It does not help for derived objects.

createSelector memoization is required when the selector derives new objects/arrays from inputs. Memoization keeps the output reference stable as long as inputs are ===.

Deep equality moves cost from rendering into selector evaluation and is generally not recommended for moderately nested trees.

5. Quantify cost and verify fix

• Measure selector compute with console.time('sel') / console.timeEnd('sel') around the selector body during a Profiler recording.
• Apply the fix: stable selector reference + createSelector for derived data, or shallowEqual for shallow slices.
• Re-record the same dispatch. Compare render count and total commit time in Profiler and selector compute time. If render count drops but selector time rises, the bottleneck moved.

Assumption: you are on React-Redux v8 with Redux Toolkit and selectors are currently using default === equality. If selectors are created inline, stabilization is required before any equality strategy will help.

One missing detail that changes the recommendation: are the problematic selectors defined inline inside the component body or imported as stable module-level functions? Inline definitions require moving or useCallback before memoization can be effective.