Sharing cache between different requests

[Wassap124]

Hey!
Asking here cause I'm surely not the first to have tackled this.

Say I wanna get myself posts using GET /posts, and later, i wanna do GET /posts/1,
There's no real reason to fetch that post, since i'd already got it in cache, it's just a cache key management thing, right?

Also, say I create a new post using POST /posts.
I want to update GET /posts cache in advance, and add that new post to it, since I know it should be added there

So I wanted to ask, before i try to reinvent the wheel, if anyone had tackled this before, and if you have a good solution for such a use case.

[samhirtarif]

You should be able to use getQueryData for the first case, just get the cached data for the /posts key and fetch the relevant item?

And setQueryData for the second case. After creating a new post you can update the data for the GET /posts by using the setQueryData on with the key you used for GET /posts and the new data

[Wassap124]

Thanks for replying!

I don't think I want to use getQueryData.
The most common use case I see in my mind is

• I fetch all posts.
• I show a list of posts, meaning I already have them
• I press on a post to enter it's "page"
• the UI would try to fetch THAT particular post
• BUT - I already have that
• So i want, that in case someone does a fetch of a single post, to be able to assert if i already "have" it or not

So my general idea (and correct me if you think it's abusing RQ), is after I fetch all posts, to use setQueriesData for all queries that fetch posts/1, /posts/2 etc.

[Wassap124]

I want that when a person would try to fetch a single post, and in the case it was included in the "bigger" fetch, it would be seamless for them

[TkDodo]

Have a read here: https://tkdodo.eu/blog/seeding-the-query-cache#seeding-details-from-lists

[samhirtarif]

^ The link that TkDodo shared explains what I was saying in much more detail and with an example 👍🏻

[Wassap124]

Thanks @TkDodo!
I guess a lot of people encounter the seeding use-case, huh?
Wonder how there's no auxiliary package no-one's made yet for structuring cache seeding in RQ

[Wassap124]

Im certain im not the first, nor the only person that encounters this issue - where I want to sync up different caches.
don't you think that a lot (if not most) users would require this ability?

Also - should i really do this to every different entity type I have? that could reach a good few dozens of different entity types.

again - It sounds to me like a lot of repeated code that a lot of ReactQuery users would appreciate

[TkDodo]

I guess a lot of people encounter the seeding use-case, huh?

not really, no. Usually, the list queries don't have all the information that you need for the detail queries - it's a subset. Seeding only works if the list endpoints returns the exact same structure as the detail endpoint. At that point - why would you need a detail endpoint at all?

const useTodos = (select) => useQuery({
  queryKey: ['todos'],
  queryFn: fetchTodos,
  select
})

const useTodo = (id) => useTodos(todos => todos.find(t => t.id === id))

with this, you'll get:

useTodos() // gives you a list
useTodo(1) // gives you the first todo