NgRx/Entity - When to spread, when to not spread, that is the question...

[mikerentmeister]

After I had an experience yesterday detailed in this discussion, I have a question about when it might be good to not spread the state. My state and reducers for entities looks like this:

export interface CollectionState<T> extends EntityState<T> {
  isLoading: LoadingState;
  error: IErrorInfo | null;
  isSaving: SavingState;
};
export type EmployeesState = CollectionState<IEmployee>;

...
on(employeesActions.loadAll, (state) => {
  return { ...state, isLoading: LoadingState.Loading, error: null };
}),
on(employeesActions.loadSome, (state) => {
  return { ...state, isLoading: LoadingState.Loading, error: null };
}),
...

Seeing as how the store of entities could be quite large, and nothing is changing with them, would it be a redux anti-pattern to decided to not spread the whole state? I know that NgRx uses distinctUntilChanged underneath the hood for its selectors. That will work great for the primitive values, but not so much for the entities dictionary. So theoretically would it be acceptable to modify the reducers to look something like this instead, so that distinctUntilChanged wouldn't fire for the entities?

on(employeesActions.loadAll, (state) => {
  state.isLoading = LoadingState.Loading;
  state.error = null;
  return state;
}),
on(employeesActions.loadSome, (state) => {
  state.isLoading = LoadingState.Loading;
  state.error = null;
  return state;
}),

I know that this technically breaks immutability, so I was thinking maybe this would be a viable option instead, to play more by the rules and create a new object, but still not trip the distinctUntilChanged:

on(employeesActions.loadAll, state => {
  return {
    ids: state.ids,
    entities: state.entities,
    isLoading: state.isLoading,
    error: state.error,
    isSaving: state.isSaving
  };
}),
on(employeesActions.loadSome, state => {
  return {
    ids: state.ids,
    entities: state.entities,
    isLoading: state.isLoading,
    error: state.error,
    isSaving: state.isSaving
  };
}),

What are your thoughts?

[twittwer]

From my understanding the entities will stay the same when doing the spread.
An explicit selector for the entities object, like provided by EntityAdapter, would not emit when spreading the state but reusing the entities.

const selectFeature = createFeatureSelector();
const { selectEntities } = entityAdapter.getSelectors(selectFeature);

on(actionA, state => ({ ...state, entities: { ...state.entities }, isLoading: true }))
on(actionB, state => ({ ...state, isLoading: true }))

• actionA
  • selectFeature: would be executed & emit new value
  • selectEntities: would be executed because of selectFeature emission and because the entities reference changed it will emit as well
• actionB
  • selectFeature: would be executed & emit new value
  • selectEntities: would be executed because of selectFeature emission but because the entities reference is still the same it will not emit again

[mikerentmeister]

@twittwer - I totally agree, that was my line of thinking as well. However, my switchMap to select employeesByIds is firing when the current employeesActions.loadSome reducer is being called. These are my selectors:

export const list = createSelector(feature, selectAll);
export const listIds = createSelector(feature, selectIds);
export const listEntities = createSelector(feature, selectEntities);

export const employeeById = (id: number) => createSelector(feature, (state) => state.entities[id]);
export const employeesByIds = (ids: number[]) => createSelector(feature, (state) => {
  return ids.map(id => state.entities[id]);
});

So what I gather from your response is that my employeesByIds selector is firing because it's being based off the feature selector, and instead I should base the employeesByIds selector off the selectEntities selector, like this?

const { selectAll, selectEntities, selectIds, selectTotal } = adapter.getSelectors();
export const listEntities = createSelector(feature, selectEntities);
export const employeesByIds = (ids: number[]) => createSelector(listEntities, (entities) => {
  return ids.map(id => entities[id]);
});

Could basing it off the listEntities selector have unintended consequences down the road, like not firing, then the actual entity is updated through the adapter? I haven't really dug into how the adapter updates the state underneath the hood.

[mikerentmeister]

Sure enough, the switchMap doesn't fire when I base the selector off listEntities instead of the feature selector. The question still remains: Could basing it off the listEntities selector have unintended consequences down the road, like not firing, then the actual entity is updated through the adapter? I haven't really dug into how the adapter updates the state underneath the hood.

[twittwer]

In case of an entity update the entities object is cloned so the your listEntities selector would emit.

[mikerentmeister]

@twittwer - thank you so much!! That clears everything up for me. I really appreciate your insights!