Diagnosing unnecessary re-renders with subscribeWithSelector middleware

The short answer

To isolate the cause of re-renders, use the React DevTools Profiler in the browser to identify if a component is rendering due to a new selector reference, and use listener invocation counting in Node to verify if the equality function is correctly suppressing notifications. Avoid relying on inline selector logging, as selectors execute on every store update regardless of whether the equality function prevents the subsequent listener call.

Choosing the measurement approach by selector shape

For inline object selectors like s => ({ a: s.a, b: s.b }), the Profiler is the most effective signal. Enable "Record why each component rendered" and trigger the update. If the Profiler indicates the component rendered because a hook changed—and the value is a new object reference—the default Object.is comparison is failing because the selector returns a fresh object every time.

Note that React 18 automatic batching may coalesce multiple store updates into one render. To get a 1:1 signal of store updates to renders, wrap the triggering action in flushSync or move the test to a Node environment.

Verifying shallow equality in a Node-only test

Since subscribeWithSelector is a store-level enhancer, you can verify equality behavior without mounting React. The listener only fires when the equality function returns false:

import { create } from 'zustand';
import { subscribeWithSelector } from 'zustand/middleware';
import { shallow } from 'zustand/shallow';

const store = create(subscribeWithSelector(() => ({ a: 1, b: 2, unrelated: 0 })));
const selector = (s) => ({ a: s.a, b: s.b });

let calls = 0;
store.subscribe(selector, () => calls++, { equalityFn: shallow });

store.setState({ unrelated: 99 });      // slice unchanged
console.assert(calls === 0, 'listener fired on unrelated change');

store.setState({ a: 2 });               // slice changed
console.assert(calls === 1, 'listener did not fire on slice change');

If the first assertion fails, the equality function is missing or improperly configured. If both pass, the store logic is sound, and any remaining browser re-renders are likely caused by unstable selector references or parent component updates.

When does shallow cost more than it saves?

shallow comparison cost scales linearly with the number of keys in the selected slice. As a general heuristic, for slices with fewer than 50–100 keys, the comparison is typically cheaper than a full React render and reconciliation cycle. Once a slice exceeds a few hundred keys, the overhead of the comparison can rival the render cost, particularly during high-frequency dispatches (e.g., mouse movements).

To determine the crossover point for your specific data shape, run a microbenchmark:

import { performance } from 'node:perf_hooks';
const x = buildSlice(), y = { ...buildSlice() };
const t0 = performance.now();
for (let i = 0; i < 100000; i++) shallow(x, y);
console.log(`Cost per 100k calls: ${performance.now() - t0}ms`);

One detail that changes the recommendation

If your selector is defined inline inside a component, it is recreated on every render. Stabilize the selector reference (by moving it outside the component or using useCallback) before benchmarking equality functions. If you can confirm whether re-renders occur on every store dispatch or only those affecting the selected slice, you can immediately distinguish between an unstable selector reference and a missing equality function.