Best practice for multiple entity instances?

[mrlubos]

Hey everyone! I'm sure this must've been mentioned somewhere already, but cannot find any related discussions.

It's pretty common in REST APIs to have an endpoint returning Entity A and another endpoint returning an array of entities of type A with some additional information. As an example, imagine you have a specific search result (with keys text, id) and an array of results for the autocomplete dropdown, but this response also includes information about which filters are applied.

As it is, I use 2 react-query cache keys for each one of these calls, let's call them entity and entity-list. All is good until Entity A becomes stale, e.g. when you update it. As an example, imagine a user suggesting edits to the search result because text contained incorrect information. What I'd do right now is update the local cache of Entity A (entity) with the returned data from the update call. This works, but only if I ensure my array of results (entity-list) gets invalidated.

Here's my question. Invalidating related queries is tedious, error-prone, and wasteful because we already have the fresh data in entity. Is there a best practice for handling this issue? In Redux, you'd keep each entity in Redux store accessible by id. Then you just need to update that object and all your selectors will continue working with the latest data. What's the react-query equivalent of this functionality?

Thanks!

[TkDodo]

Invalidating related queries is tedious, error-prone, and wasteful because we already have the fresh data in entity. Is there a best practice for handling this issue?

You can always manually keep the entity-list up-to-date after the mutation of the entity, something like:

useMutation(
    mutateEntity,
    onSuccess: (newData) => {
        queryCache.setQueryData(previousEntityList =>
            previousEntityList.map(
                entity => entity.id === newData.id ? newData : entity
            )
        )
    }
)

[mrlubos]

Correct. However, if I had to choose between 2 instances in react-query (1 of them stale) and making extra requests, I'd choose option 2. Ideally, we could solve this without making any additional requests or manually tracking entities, would be curious to hear suggestions. For now, I am only thinking about creating some wrappers around react-query to store entity instances in a separate query, but that doesn't feel right either.

[TkDodo]

Ideally, we could solve this without making any additional requests or manually tracking entities, would be curious to hear suggestions.

Since there is no "dependency graph" between queries, I wouldn't know how to make that automatically. If you find yourself having a lot of entity-list -> entity-detail cases, you could make a custom wrapper that always invalidates or manually updates the list in a more generic way, so that you can use it for user-list / user-detail as well as article-list / article-detail etc, basically:

invalidateQueries(`${entityName}-list`)

[mrlubos]

Hmm, I think this could work for now, thank you @TkDodo! Do you know if there are any plans to add dependency graph to react-query?

[TkDodo]

I am not aware, but if you have a concrete proposal of how to make it happen, feel free to open an issue and we can discuss it there. I just think that mutations could also potentially need to invalidate different queries depending on parameters / the result from the backend, so I'm not sure you can always pinpoint "migration X invalidates queries Y and Z" in a generic way so that the library can do it for you, but maybe I'm wrong :)

[mrlubos]

You're 100% right. A typical example is creating an item where the GET query returns a list of all instances, possibly sorted or otherwise filtered. I think it would be valuable to add at least an example/best practice to docs once we figure out a way to handle stale data due to these actions because I didn't catch it mentioned anywhere. As I mention in the original post, in Redux I used to do this manually and it's A LOT of boilerplate code, so if we can find a way to do this cleanly in react-query, that would save people a lot of time. In my mind that should be possible since react-query is a "server-side state" cache. 🤞

[mrlubos]

Hi @tannerlinsley, I wonder if you have any insights into this topic? Thanks in advance!

[criticalx7]

maybe try some normalize cache solution ?

[mrlubos]

Hi @criticalx7, thank you for your reply! Can you please elaborate on your suggestion? I'd like to understand it further

[sergiodxa]

What I usually do is that if I have an entity and entity-list I call the keys ["entity", id] and ["entity", "list"]. This way I could do queryCache.invalidateQueries("entity") and it will invalidate the list and each entity.

[mrlubos]

Hi @sergiodxa, that makes sense, thanks! That should solve part of the issue, ensuring all related queries are correctly invalidated. What do you think about being able to update all related entities locally without making any extra requests at all? What I am imagining is react-query would internally hold an object with entities accessible by their unique keys (id) and if there's any change to the entity, all relevant queries pointing to that instance would automatically return the latest data as they wouldn't hold duplicate state as they do today.