NgRx Selector Memoization When Input References Change Each Change Detection Cycle

Short answer

Yes. If the selector receives a new object reference on each change detection cycle, the default NgRx memoization will re-run the projection even when the underlying data is deeply equal. The store's immutable state does not help if the changing reference is a component-supplied props object. If the selector's inputs are store slices that did not change, their references stay the same and the projection is skipped.

Why the recomputation happens

createSelector memoizes the projector by comparing the input results with reference equality (===). When a component method returns a fresh object each render and that object is passed as props to a parameterized selector, the selector sees a new input reference. The memoization check fails, so the projector runs again. The projected value may still be equal, but the work has already been done.

Recomputation and emission are separate. Even if the projector returns the same reference and store.select suppresses an emission with distinctUntilChanged, the projector still executed. That is the cost you are trying to avoid.

Does createFeature's immutable option fix it?

No. There is no immutable option on createFeature that changes selector memoization. Immutability is a developer contract enforced by your reducers and dev-mode checks; it does not stabilize references for selectors. If you saw an immutable flag elsewhere, it is not a runtime switch for this problem.

Would a custom comparator help?

It can. Depending on your NgRx version, createSelector may accept a memoization config with a custom equality check. A comparator that treats two props objects as equal when their contents match will prevent the projector from re-running. But it is not free:

• The input selectors still run on every call.
• The comparator runs on every call, and deep comparison can be more expensive than the projector you are trying to skip.
• The comparator only sees the inputs passed to the selector, not the whole store state.

So a custom comparator is not "the same effect without overhead." It trades reference stability for comparison cost. Use it only when you cannot stabilize the reference at the component level.

Preferred fix: stabilize the input reference

The root cause is the component pattern, not the selector. Move the object creation out of the template or method that runs each change detection cycle.

1. Compute the props once and store them in a component field.
2. If the props depend on an input, derive them in ngOnChanges or from an observable with distinctUntilChanged.
3. Pass primitives instead of an object when the selector only needs one or two values. Default memoization compares primitives by value.
4. Use a pure pipe or a memoized function if the template must derive the object.

Example of a stable reference:

// Instead of: this.store.select(selectThing, this.getProps())
// where getProps() returns { id: this.id } on every call:

private readonly props = { id: 'fixed-id' };

// Or derive once when the input changes:
ngOnChanges(): void {
  this.props = { id: this.id };
}

If the props must change, make the change explicit and reference-stable. Then the selector will skip the projector when the store slice and props are unchanged.

How to verify in your app

1. Add a counter or console.log inside the selector projector.
2. Log Object.is(previousProps, nextProps) in the component or in a custom memoize function.
3. Run the app and observe the counter across change detection cycles without store changes.
4. Replace the fresh object with a stable field and confirm the projector run count stops increasing.

If the counter still increases with a stable props reference, check whether the selector is being re-created (for example, inside a component method) or whether an input selector is returning a new reference.

One detail that changes the exact API advice

Which NgRx version are you using? The core reference-equality behavior is stable, but the shape of the custom memoization config for createSelector differs across versions. Check your installed version's createSelector overloads before adding a comparator.

Assumption: NgRx v13+ and Angular's default change detection. Verify the memoization config API against your installed version.