Select latest cached result from RTK Query endpoint

[tkharuk]

Hi!

I find myself in need to access some data in different components.
And sometimes it is a pain to assemble all of the arguments needed every time.

Is there a way to access data from latest entry cache without the need to pass all of the arguments for the key?

I can see data just there in the tree, just need to find the best way to get it into components

technically, I could "select" it with some matchers and assumptions

export const selectTable = (state) => {
  const queriesCache = state.api.queries;
  const tableCacheKey = Object.keys(queriesCache).filter((name) => {
    return /getTableData/.test(name);
  })[0];

  return queriesCache[tableCacheKey] ?? {};
};

and this will work for me for some cases, but maybe there is a better way to achieve this?

[markerikson]

Can you clarify what you mean by "latest" in this case?

[markerikson]

None of the cached endpoint entries have an inherent notion of "sequence". They're all stored based on a serialization of the query args.

That said, those cache entries do have timestamps inside that you could use to compare and find the most recently updated entry.

[msutkowski]

To add on to this - the data for a query with a given arg is always going to be the latest entry. What you're trying to do here is extremely problematic if you have multiple getTableData requests that have different args and doesn't scale at all. If you want a safe way to do this:

1. use a context for the query arg
2. put your current query arg in a slice being that you're already using redux. { someUniqueKeyForThisTable: arg}, and pull it back out for your useQuery

[tkharuk]

@markerikson I suppose timestamp won't help me for already cached entries.

@msutkowski yeah, that's what I've ended up doing and it does feel like a correct way to do it. But also like a bit of a tedious way when my args come from different places at different time. And I just use query.endpoints to fetch and assembling them together in some slice is a bit weird, or maybe not. But there is also a problem of cached queries not firing updates in a matcher.

[markerikson]

Assuming you're talking about #1717 , I believe there is no fulfilled action dispatched when there is a cache hit. Instead, there is a rejected action dispatched with some kind of a "reason: cached" value inside meta, I think.

[phryneas]

It's action.meta.condition: true, which means that the asyncThunk has been prevented from running due to a condition (in this case: data already in store).