Has anybody built a "indexed-by-ID" cache using react-query?

[subhan-nadeem]

I am using react-query for all of my data fetching logic in my react app. At a basic level, I have something like useBooks(bookIds) that uses react-query fetches Book objects based on bookIds, like so:

const useBooks = (bookIds) => {
    return useQuery(bookIds, (bookIds) => fetchBooksFromServer(bookIds));
}

I want to implement the following functionality when calling useBooks:

• If a bookId in the array bookIds already exists in a previously cached query, use that cached Book object rather than querying the server for it
• As the user queries for more and more Books, keep adding them to this indexed-by-id cache

I'm wondering if anybody has figured out how to do this in a clean way? I've been thinking about coupling use of the react-query hook with a context provider but have not been able to flesh it out in its entirety yet.

[sergiodxa]

You can use initialData to read from another query https://react-query.tanstack.com/docs/guides/initial-query-data#initial-data-from-cache

[subhan-nadeem]

Right, I think I'm trying to wrap my head how to leverage this to build an indexed-by-ID cache.

For example, considering useBooks(bookIds), the user may request an arbitrary array of bookIds, I may be able to go through all old useBooks cached queries, and if some of the existing ones match, set those as initialData. I would want to make sure the server does not fetch Books that were set in initialData, but still fetches Books that were not set in initialData. It seems as if I can tell the server whether or not to fetch with initialStale: () => boolean, but this seems to be an all-or-nothing check.

The above logic seems cumbersome and perhaps a little expensive (iterating over all existing queries, checking to see if the data exists in one of the old queries), which is why I'm wondering if there is a proper way to leverage react-query to pop things in and out of a indexed-by-id cache.

[sergiodxa]

I think what you want is a normalized store for your server state, like the one you could build with Redux. In React Query, the cache is query based and not normalized, so you can try to use an approach like use initialData to get the individual book info from a list to get a better perceived performance while you revalidate against the server but you will need to hack React Query a lot if you want to achieve a normalized cache.

You could, as an example, manually fill the cache with individual Book entities and then in your useBooks query function you can read from the cache or fetch the date you don't have. Note if you do this, you will need to have a way to force a revalidation.

As a personal recommendation, don't try to work with RQ as if it was Redux, instead forgot about a normalized state and cache by query. If your reason to avoid fetching data from the API is because the API is slow, fix the API or add an HTTP cache or CDN to improve the performance of the API, if you do that, you will stop caring about fetching data from the API because the request will resolve fast enough.

[subhan-nadeem]

Do you have any insight on whether or not there is use in building a "normalized store"? The reasoning behind why I wanted to initially build a "indexed-by-ID" cache for certain data types was because these data types are used across several different pages in the UI, so I figured there would be use in reusing the data rather than refetching it any time the user queries for it in an effort to improve UX. There is also a request for this from server-side development, which I am assuming is for performance/server-load reasons.

I can try the initialData approach, but because objects are not indexed by ID, I would have to do an O(nm) query (n being length of all Book queries, m being length of longest bookIds array) to find objects that already exist in previous queries; this is still definitely faster than a server query.

[tannerlinsley]

TLDR, Normalized stores:

• Can help keep individual items that are shared between list/index queries up to date
• Can improve the lookup performance of single items or entities from other queries

However:

• They cannot guarantee order, existence or removal of specific items from index/list queries and thus can lead to a false sense of truth.
• The lookup performance characteristics are 99% of the time very negligible unless you are caching tens of thousands of entities or more on the client.
• Garbage collection of said normalized store becomes extremely difficult since you have to start tracking entity dependencies across the entire application, etc. Most stores just hold on to everything forever or implement an LRU or memory-based eviction strategy, which then results in an incomplete/partial store anyway.

More in depth:

Normalize storage for index/list calls can potentially help keep shared entities in those calls up to date without making further round trips to the serve, however it cannot guarantee or maintain the order and absolute shape of those list/index call. For example, if you already have a portion of the items that would normally come back from a list/index call, you have absolutely no idea where those items will end up in the list call until you make it, since the server is the ultimate source of truth. This also happens for items that get added or removed from list/index calls. You cannot know exactly where new items should be placed, or whether an item can be safely removed from an index/list call without replicating all of your server logic in your client. This is usually a waste of code and honestly really messy. So while normalized storage might feel like it helps keep your individual entities synced up across your application, it can give you a false sense of truth on the order and contents of those lists. In the end you can only know for sure if you refetch the entire list from the server, at which point, you might as well not have wasted your code/time with normalization and instead just kept track of which list/index queries need to be refetched and when.

When it comes to individual assets, normalized stores can help a smidge by making every known entity available in a flat lookup. If you have tens of thousands of entities on the client, this would probably make a difference, but that's not likely at all. Most apps may have hundreds or maybe a few thousand total entities of a few types, and you probably won't be iterating over all of those types anyway. At the end of the day as long as you can look up an existing entity from other list calls and it's not prohibitively expensive, then that should work just fine. Another aspect of looking up normalized entities is that you need to know if the entity is "fresh" or not, which makes it difficult to know when and if you should request it from the server. This pattern is possible with both normalized and denormalized lookups though, so neither offers a great advantage. It's much more reliable to populate placeholder or preview data using existing lookups, then request the actual entity from the server in the background. This way you are sure you have the most up to date version of the entity instead of an outdated version you found from an unrelated query.

All things considered, as long as the utilities/semantics/ease-of-use of the API is good, normalized/denormalized discussions usually hinge around saving bandwidth or relieving a server of congestion at the expense of a surety that your data model on the client matches what's on your server as closely as possible.