EntityAdapter selectAll ordering stability when sortComparer omitted and sort-relevant properties updated

Direct Answer

EntityAdapter does not re-sort the internal ids array when updateOne or updateMany changes a sort-relevant property, even when a sortComparer is configured. The comparer runs only while the ids array is mutated by add, upsert, remove, or setAll. Because selectAll reads from ids, the displayed order remains stale after a property update unless you sort at read time or explicitly replace ids in state.

Confirmed Facts and Likely Explanation

Confirmed: updateOne updates the entity map and returns the existing ids array reference unchanged. selectAll maps over ids, so it cannot surface a new position for the changed entity.

Likely explanation: Without sortComparer, ids reflects insertion order. Eager and lazy feature modules may upsert entities in different sequences, so the same collection can have different ids sequences depending on load timing. In signal-based stores (NgRx v16+), selectAll emits a new array reference when the entities signal changes, but the order inside that array still follows the unsorted ids sequence.

Recommended Pattern: Sort at Read Time

Do not re-add entities. Derive a sorted collection from selectAll so state stays untouched and every property update is reflected immediately.

Classic Store with createSelector

import { createSelector } from '@ngrx/store';

export const selectSortedEntities = createSelector(
  selectAll,
  (entities) => [...entities].sort((a, b) => a.updatedAt - b.updatedAt)
);

Signal Store (NgRx v16+) with withEntities

import { computed } from '@angular/core';

const sortedEntities = computed(() =>
  selectAll().slice().sort((a, b) => a.updatedAt - b.updatedAt)
);

Bind the derived collection in your template. This avoids mutating ids on every property change and prevents excessive re-renders.

When You Must Keep ids Sorted in State

If other selectors or persistence depend on the stored ids order, dispatch a synthetic reSort action after batches of updates, not after every single update.

Classic Store

adapter.setAll(selectAll(state).slice().sort(sortFn), state);

Signal Store

patchState(store, { ids: [...ids()].sort(sortFn) });

No Built-In Invalidation Mechanism

The functional createEntityAdapter exposes no reSort, invalidateSort, or automatic property-watch trigger. You must either sort at read time or replace ids explicitly through an action.

Verification Step

1. Provide a sortComparer to createEntityAdapter.
2. Dispatch updateOne on a field used by the comparer.
3. Log selectAll before and after the update.
4. Confirm the array reference changes in signal stores but the entity order does not; in classic stores both reference and order stay the same.

Then apply the derived selector or computed signal above and confirm the logged output reflects the new sort position immediately.

One Missing Diagnostic Detail

Are you using the classic Store with createSelector, or the signal-based signalStore with withEntities? The read-time sorting pattern works for both, but the implementation differs: classic uses createSelector, while signal stores use computed over selectAll. Knowing your runtime determines which snippet applies.