Implement a Memoized Selector That Only Recomputes When Its Specific Inputs Change (Reselect-Style)

Q: Implement a Memoized Selector That Only Recomputes When Its Specific Inputs Change (Reselect-Style)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the whole real point of this pattern — genuinely SKIPPING recomputation, verified by checking that the exact SAME array reference is returned, not merely an equal-looking new one — was confirmed directly, not assumed from the caching logic alone. ## 1. The problem, restated `createSelector(inputSelectors, resultFn)` returns a memoized selector function: each call runs every `inputSelector` against the given state to get their CURRENT outputs, and only re-runs `resultFn` (the expensive derivation) if at least one of those specific outputs has genuinely CHANGED since the last call — an unrelated change elsewhere in state must not trigger a recompute. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Compare full state, or just input selector outputs? | Just the outputs, genuinely — comparing the whole

The problem

Problem, as an interviewer would state it: "Implement a Reselect-style createSelector(inputSelectors, resultFn) — a derived-state selector that only recomputes when one of its DECLARED input selectors' own output actually changes, ignoring unrelated state changes entirely."

Examples:

Code

const getFilteredItems = createSelector([getItems, getFilter], (items, filter) => items.filter(i => i.includes(filter)));
getFilteredItems(state); // computes
getFilteredItems({ ...state, unrelatedField: 2 }); // returns the SAME cached result, no recompute

Clarifying questions expected:

Does the memoization compare the FULL state object, or just the specific input selectors' own outputs?
Should the comparison be a shallow reference check (===) or a deep equality check?
Does the selector need to support MULTIPLE independent instances, each with their own cache?

Code / implementation expected: Yes — real, direct proof that an unrelated state change does not trigger recomputation (same cached reference returned), while a relevant one does.

memoization
redux
state-management

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the whole real point of this pattern — genuinely SKIPPING recomputation, verified by checking that the exact SAME array reference is returned, not merely an equal-looking new one — was confirmed directly, not assumed from the caching logic alone.

1. The problem, restated

createSelector(inputSelectors, resultFn) returns a memoized selector function: each call runs every inputSelector against the given state to get their CURRENT outputs, and only re-runs resultFn (the expensive derivation) if at least one of those specific outputs has genuinely CHANGED since the last call — an unrelated change elsewhere in state must not trigger a recompute.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Com

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a memoized selector returns the same cached reference for an unrelated state change and recomputes for a relevant one