Correct mental model of new merge option, with serializeQueryArgs and forceRefetch

[einarq]

I think I'm struggling a bit to get the correct mental model of how I'm supposed to use the new options in queries to support loading more etc.

I'll try to explain the scenario first:

• I have a getPermissions endpoint, which takes several parameters ({surveyId: string, filter: string, orderBy: string, orderDir: string, skip: number})
• There is a Load More button on the list, which should load more and merge the responses. When the skip parameter changes, we want to load more results and merge the options.
• I only want to merge the responses the skip param was changed but everything else was kept the same. If more params change, we should discard the cache and get new results.

Am I correct that the logic for this needs to live in the forceRefetch handler? Will the merge handler only get called if the forceRefetch option returns true? Seems to me that the merge handler could use some more information about next and previous args etc, but as I said I probably have the wrong mental model. I guess I need to understand more about the intention of the forceRefetch handler especially (the other two seem more obvious).

Are there any more complex examples I could look at than the one found in the release notes?

[einarq]

Actually think I got it working now. Funny how writing out the problem often helps in getting the correct mental model.

Here is my current implementation, is there anything that could be simplified?

  serializeQueryArgs({queryArgs}) {
    return omit(queryArgs, 'skip');
  },
  merge(currentCache, responseData) {
    currentCache.permissions.push(...responseData.permissions);
    currentCache.hasMore = responseData.hasMore;
  },
  forceRefetch({currentArg, previousArg}) {
    if (!currentArg || !previousArg) {
      return false;
    }

    const {skip: currentSkip, ...currentArgs} = currentArg;
    const {skip: previousSkip, ...previousArgs} = previousArg;

    const serializedQueryArgsChanged = !isEqual(currentArgs, previousArgs);

    if (serializedQueryArgsChanged) {
      return false;
    }

    return currentSkip > previousSkip;
  },

[einarq]

New issue though...
Does adding these handlers change how automatic tag invalidation works? I have functionality in the list to revoke permissions as well. When calling the revoke endpoint, the tags should be invalidated.

Without these handlers, everything works fine. I can add permissions to the list, and I can revoke permissions from the list. Both are calling endpoints that invalidate the list.

With the handlers however, nothing happens. Do I have to manually refetch when enabling these handlers?

[einarq]

If I try to do a manual refetch, I get this issue. So I'm probably doing something wrong...

[einarq]

And now I noticed that RTK 1.9.1 was out, which gives merge a third argument. This came in handy.

[markerikson]

Heh, afraid the short answer is that things like merge and forceRefetch have been implemented, tested, and documented, but we haven't done much beyond that :) These are things that were asked for, so we implemented them, but at that point it's up to users to do something with them.

[einarq]

Sure. I’ve seen some of those discussions I think, and I guess it was mainly about having some way of supporting pagination etc.How it was implemented in the end was probably more a maintainer decision?The addition of the extra merge arg was a good improvement, probably due to user feedback. Thinking there could other potential improvements as well. And as I said, to me at least it’s a bit unclear what the responsibility of the forceRefetch handler is. On 30 Nov 2022, at 16:19, Mark Erikson ***@***.***> wrote: Heh, afraid the short answer is that things like merge and forceRefetch have been implemented, tested, and documented, but we haven't done much beyond that :) These are things that were asked for, so we implemented them, but at that point it's up to users to do something with them. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>