Observing state changes in effects

[STOWouters]

Hello all,

I have a component store that keeps track of the current page as well as the active filters. There is also some form of pagination which will call the fetchItems() effect under some condition (e.g., when you scroll down far enough). The implementation looks something like this:

export interface ItemsState {
  page: number;  // current page
  filters: Filter[]; // current active filters
  items: []; // fetched items
}

@Injectable()
export class ItemsStore extends ComponentStore<ItemsState> {
  // ...

  fetchItems = this.effect(($) => $.pipe(
    exhaustMap(() => this.select((state) => ({
      page: state.page + 1,
      filters: state.filters,
    })).pipe(
      switchMap((params) => {
        return this.itemsService.getItems(params.page, params.filters).pipe(
          tapResponse(
            (items) => {
              // update state, but this triggers the above selector again, causing to keep fetching the next page
              this.patchState({
                 page: params.page,
                 // update items...
              });
            },
            () => { /* some error handling */ },
          ),
        );
      }),
    )),
  ));
}

The issue here is that the patchState call causes the selector in the first line to be triggered again, which in turn will fetch the next page, causing an infinite loop of fetching the next page (until it runs out). I am wondering if I am doing something fundamentally wrong with this implementation or is there a way to patch a state without triggering the selector?

I have also tried to use withLatestFrom(this.select(state => ...)) or take(1) instead, but while that does stop the infinite loop, it does not observe the changes on the filters, which is kind of required since fetching the items from the currently running request (if any) should be cancelled whenever the filters change.

Is there a way to observe changes in the state and cancel the running effect or another NgRx way to achieve this?

[david-shortman]

Yes there is a way. What you want is to have a selector that only emits a new value when your parameters have actually changed:

@Injectable()
export class ItemsStore extends ComponentStore<ItemsState> {
  // ...

  // 👇 Declare selectors that can be memoized, and will only emit distinct values
  page$ = this.select((state) => state.page);
  filters$ = this.select((state) => state.filters);
  // 👇 Then create a composite selector that will only emit a new value when one of the input selectors emits a new, distinct value
  itemsRequestParams$ = this.select(
    this.page$,
    this.filters$,
    (page, filters) => ({
      page: state.page + 1,
      filters: state.filters,
    })
  );

  fetchItems = this.effect(($) => $.pipe(
    exhaustMap(() => this.itemsRequestParams$).pipe(
      switchMap((params) => {
        return this.itemsService.getItems(params.page, params.filters).pipe(
          tapResponse(
            (items) => {
              // update state, but this triggers the above selector again, causing to keep fetching the next page
              this.patchState({
                 page: params.page,
                 // update items...
              });
            },
            () => { /* some error handling */ },
          ),
        );
      }),
    )),
  ));
}

This concept applies to NgRx global store selectors that use createSelector, and computed Signals. You have to break up derived values into smaller parts that can be memoized.

Unrelated: I noticed you're using exhaustMap to handle this request that looks like user search. I think this will have unexpected behavior. exhaustMap, for each source value, will initiate the request and then ignore all source values until the request completes. This means that a user who's interacting with a table with pagination could click a page number, then, while the table is loading, select a filter, but the filter input will be ignored until the request for the page number change completes. You probably want to use switchMap here so that the user's latest input to the filters and page is respected. You can use debounceTime if you want to avoid kicking off requests immediately.