When do selectors recalculate?

[anno1985]

Hi all,

Given that (provided I understand the docs correctly) we should create deep copies of the state,

Store is built on a single, immutable data structure which makes change detection a relatively straightforward task using the OnPush strategy.
https://ngrx.io/guide/store/why#immutability-and-performance

Note: The spread operator only does shallow copying and does not handle deeply nested objects. You need to copy each level in the object to ensure immutability.
https://ngrx.io/guide/store/reducers#creating-the-reducer-function

and given that selectors recalculate when their inputs change,

When using the createSelector and createFeatureSelector functions @ngrx/store keeps track of the latest arguments in which your selector function was invoked. Because selectors are pure functions, the last result can be returned when the arguments match without reinvoking your selector function.
https://ngrx.io/guide/store/selectors#selectors

I was wondering how selectors determine if their input changed - or, put differently: when do they recalculate?

Do they run a deep compare, or do they somehow check by reference?
If they check by reference, won't they constantly recalculate, if we use deep copies of the state?

Cheers,
Chris

[david-shortman]

The inputs for selectors are determined when the state changes. The inputs are compared by reference for objects, and by value for primitives.

Selectors don't have to be recalculated if selectors are composed in small slices that can be memoized.

By looking at a simplified implementation of how createSelector and store.select work, then you'll see how selectors get updates.

createSelector is a function that simply creates another function that takes in state and returns a value. Here's a simplified example:

function createSelector(...otherSelectors, projector) {
  // Define an internal state for memoization
  let lastMemoizedArguments: Array<unknown> = undefined;
  let lastMemoizedResult: unknown = undefined;

  // Return a function that, for the current state, returns either a memoized value or a new value
  return (state) => {
    // Apply the dependent selectors to the state
    const otherSelectorResults = otherSelectors.map(selector => selector(state));

    // Given the results of the other selectors, check if the memoized value is applicable to the results
    const result = lastMemoizedArguments?.every((arg, i) => arg === otherSelectorResults[i])
        ? lastMemoized.result
        : projector(...arguments);
    
    // Memoize the current result
    lastMemoizedArguments = otherSelectorResults;
    lastMemoizedResult = result;

    return result;
  };
}

So, selectors simply apply a chain of functions to a state object, and the chain will stopped being evaluated and return early when there are memoized results.

Then, for store.select, for every single state change, a selector is called. Duplicate values are simply ignored.

You can imagine implementing your own version of select like:

class Store<State> {
  select(selector: (state: State) => unknown) {
    return this.state$.pipe(
      map(state => selector(state)),
      distinctUntilChanged() // don't emit a new value unless the value changes
    );
  }
}

Hopefully that helps explain how and when selectors are applied.

Here's a further example:

Say we have the following selectors for finding students who have a passing grade on a test:

// Example of a manually create state selector
const selectState = createSelector(
  (state: State) => state,
  state => state
);

const selectStudents = createSelector(
  selectState,
  state => state.students
);

const selectTestGradesByStudentId = createSelector(
  selectState,
  state => state.testGradesToStudentId
);

const selectPassedTestsByStudentId = createSelector(
  selectTestGradesToStudentId,
  testGradesToStudentId => Object.fromEntries(
    Object.entries(testGradesToStudentId).filter(([_, { grade }]) => grade > 60)
  )
);

const selectStudentsWhoPassedTest = createSelector(
  selectPassedTestsByStudentId,
  selectStudents,
  (passedTestsByStudentId, students) => students.filter(student => !!passedTestsByStudentId[student.id])
);

Then when we are subscribed to this selector:

const studentsWhoPassedTest$ = this.store.select(selectStudentsWhoPassedTest);
studentsWhoPassedTest$.subscribe();

Then say the current state is:

{
  students: [{id: 1, name: 'Alice'}, {id: 2, name: 'Bob'}],
  testGradesToStudentId: {'1': {grade: 65}, '2': {grade: 55}}
}

All the selectors would be called immediately, with their arguments memoized.

If we produce a new state object where we add another student, but not another test grade, then the selectors would be evaluated like:

• selectStudentsWhoPassedTest would call selectPassedTestsByStudentId and selectStudents
  • selectPassedTestsByStudentId would call selectTestGradesToStudentId
    • selectTestGradesToStudentId would call selectState, which returns the new state object. Then the projector would return state.testGradesToStudentId, which is the same array with the same reference as the previous state
  • Then the argument for selectPassedTestsByStudentId would be the same array as the last memoized result, and so the last memoized result would be returned for selectPassedTestsByStudentId
  • selectStudents would call would call selectState, which returns the new state object. Then the projector would return state.students, which is a new array with a different reference than the previous value
• Then the arguments for selectStudentsWhoPassedTest would be the same reference for passedTestsByStudentId and a new array of students. Since one of the arguments changed, the projector would be applied to the arguments

[david-shortman]

I did a write up here- https://dev.to/davidshortman/heres-how-ngrx-selectors-actually-work-internally-15ml

[anno1985]

Thanks! So (if I wanted to change an existing student, not add a new one - for example, change student.address.postcode), when they write

You need to copy each level in the object to ensure immutability.

they'd be referring to the individual student in your example (if they were complex and not flat objects), not the entire state :
Deep copy a student, don't deep copy the entire state.
That way, selectors that would select students objects that hadn't changed wouldn't fire.

One more question regarding your example, though:
would adding a new student really change the students array, as in: create a new array (reference)?
Or would that just add one more object to an existing array, thus not triggering the selectStudents selector again?

I guess it depends on whether your reducer would students.push(newStudent) to the existing array (modifying it) or use e.g. the spread operator ([...students, newStudent]), thus creating a new one (or any other method that returns a new array, like Object.assign([], students, newStudent))?