How do you select a single property and prevent extra re-renders?
Tests selector granularity and reference equality in subscriptions. Great answer: return a primitive via a focused selector; for objects, memoize with createSelector or pass shallowEqual. Red flag: reaching for useMemo or React.memo before fixing the selector.
WHAT THIS TESTS: The interviewer wants to know if you understand how state-management libraries decide to re-render subscribed components. The core issue is reference equality. Both Redux and Zustand compare the previous and next selector result with a strict equality check by default. If your selector returns a new object or array reference every time the store updates, the component re-renders even if the data inside that object never changed. The question also tests whether you know the difference between selecting a primitive value versus deriving a new reference inside a selector.
A GOOD ANSWER COVERS: First, write a focused selector that returns exactly the primitive value you need, such as returning state.user.name instead of state.user. Because primitives compare by value with strict equality, unchanged data will not trigger a re-render. Second, if you must return an object or array, use a memoized selector utility like createSelector from Reselect to ensure the output reference stays stable when the inputs have not changed. Third, if memoization is not available, pass a custom equality function as the second argument to useSelector, such as shallowEqual from React-Redux, so that the hook compares object keys rather than object identity. Fourth, for Zustand specifically, use a selector function as the first argument to the hook and import shallow from zustand/shallow when you need to compare multiple properties at once.
COMMON WRONG ANSWERS: A major red flag is suggesting useMemo or React.memo as the primary solution. That treats the symptom at the React layer instead of the cause at the subscription layer. Another red flag is returning an inline object from the selector, like returning an object with name and age properties, without realizing that this creates a new reference on every store update and forces a re-render regardless of whether user data changed. Saying you would split the Redux store into multiple smaller stores is also a smell; the correct fix is selector granularity, not store architecture.
LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a derived list, such as filtering a large array of items, where the derived array reference changes on every dispatch even if the filter criteria did not. They might also ask what happens when a selector uses props from the component, which can create stale closure bugs if not handled with stable callback references. A third follow-up is how React 18 batching affects multiple useSelector calls in the same component.
ONE CONCRETE EXAMPLE: Imagine a Redux store with a state shape containing dashboard data with widgets, layout, and theme. A component only needs the theme string. If you write useSelector and return state.dashboard, the component re-renders whenever widgets or layout change because the dashboard object reference is new. The correct approach is useSelector returning state.dashboard.theme. If a second component needs both theme and layout, you should either use two separate useSelector calls returning primitives, or use createSelector to memoize the combined object, or pass shallowEqual to a single useSelector call.
Read the original → react-redux.js.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.