How Can I Execute Logic When Query Data is Retrieved from Cache Using @ngneat/query?

[jon9090]

Which @ngneat/query-* package(s) are the source of the bug?

query

Is this a regression?

No

Description

I'm encountering an issue where I retrieve user data using @ngneat/query with staleTime: Infinity, which generally works well. However, when navigating back to the page, the query returns results from the cache but doesn't execute the logic inside tap.

Is there an alternative way to implement the tap? Is there a function that gets invoked when data is retrieved from the cache so that I can include the necessary logic there?

 getUsers(userId: number, searchQuery: Partial<SearchQuery>) {
    return this.#query({
      queryKey: ['users', searchQuery] as const,
      queryFn: () =>
        this.userApi.fetchUsers(userId, searchQuery).pipe(
          tap((result) => {
            this.state.set({ total: result.total });
            result.hasMore && this.prefetch(userId, { ...searchQuery, pageNumber: searchQuery.pageNumber + 1 });
          })
        ),
      placeholderData: keepPreviousData,
      staleTime: Infinity
    });
  }

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in

No response

Anything else?

No response

Do you want to create a pull request?

Yes

[luii]

when navigating back to the page, the query returns results from the cache but doesn't execute the logic inside tap.

Exactly, when having staleTime: Infinity it wont even go into the queryFn to execute it. It will just take the result from the cache and thats all. I dont really like to add side-effects to something already so concise like how you do it above. I would keep the getUsers as clean as possible and leave it stateless/side-effect less - this way you cannot introduce bugs into your state management.

Is there an alternative way to implement the tap? Is there a function that gets invoked when data is retrieved from the cache so that I can include the necessary logic there?

There sure is, if you want to react to both cached and fresh results, then something like below should be fine, though my approach is on the previous version of ngneat/query, i think it can apply here too.
What i generally do is that i multicast the result to get three different streams:

• First handles the loading state
• Second handles the error state
• Third handles the success state

readonly #signal$ = this.containerState.select('widgetConfig', 'signalId').pipe(
    filterNil(),
    switchMap(
      (Id) =>
        this.#signalService.queryEntities({
          query: {filter: {Id}},
        }).result$,
    ),
    connect((shared$) =>
      merge(
        shared$.pipe(
          map(() => ({signalLoading: true, /* set total length here */ })),

          // below is pseudo code: just taken from your example
          tap(({hasMore}) => hasMore && this.#signalService.prefetch(userId, { ...searchQuery, pageNumber: searchQuery.pageNumber + 1 })),

        ),
        shared$.pipe(
          filterError(),
          selectResult(({error: signalError}) => ({signalError, signalLoading: false})),
        ),
        shared$.pipe(
          filterSuccess(),
          selectResult(({data: [signal]}) => ({
            signal,
            signalLoading: false,
            signalLoaded: true,
            signalError: null,
          })),
        ),
      ),
    ),
  );

// somewhere else i connect the observable into a state manager
// i use rx-angular here for example
// 
//    this.state.connect(merge(this.#signal$));

just for clarification on what i mean by stateless api service methods.
Not much is happening there besides error handling/reporting and deserialization of entites to align them with their corresponding model classes

  public queryEntities({
    query,
    options = {},
    requestOptions = {parsePagingHeader: false},
    queryId = undefined,
  }: {
    query: Partial<Query<M>>;
    options?: Partial<Omit<Parameters<typeof queryOptions<M[]>>[0], 'queryFn'>>;
    requestOptions?: Parameters<InstanceType<typeof HttpClient>['post']>[2] & {
      parsePagingHeader: boolean;
    };
    queryId?: string | null | undefined;
  }): ReturnType<ReturnType<typeof this._usePersistedQuery<M[]>>> {
    const key: unknown[] = [this._modelQueryKey.plural, query];
    if (queryId) key.push(queryId);
    if (options.queryKey) key.unshift(options.queryKey);

    return this._usePersistedQuery((queryKey) => {
      return queryOptions({
        ...options,
        queryKey,
        queryFn: (_) => this.queryEntitiesRaw({query, requestOptions}),
      });
    })(key);
  }

  public queryEntitiesRaw({
    query,
    requestOptions = {parsePagingHeader: false},
  }: {
    query: Partial<Query<M>>;
    requestOptions?: Parameters<InstanceType<typeof HttpClient>['post']>[2] & {
      parsePagingHeader: boolean;
    };
  }) {
    return this._httpClient
      .post<E[]>(`...redacted...`, createQueryBody<M>(query), requestOptions)
      .pipe(
        map((entities) => this._entityMapper.deserialize(entities)),
        catchError((error: Error) => {
          this._logger.error(`queryEntities: Error while querying entities of type ${this._modelURI}`, error);
          return throwError(() => error);
        }),
      );
  }

This way you can keep the services clean/stateless and leave state-management up to the feature/component/or whatever you call it