Invalidate by ID in react-query

[jjsessa]

It would be awesome if there was a way to invalidate and/or refetch all queries based on an ID. I often find myself 3-4 layers deep in a nested object and I need to invalidate every single list view in all of its parents, but I don't want to invalidate pages of those lists if they don't contain the child. This would be especially useful paired with paginated/infinite query helpers and is also a great onError default for failed mutations.

I would love to help implement this, @klis87 could you point me in right direction if this is possible and what methods from core need to be wrapped.

[klis87]

Before I answer, why do you need invalidation instead of in place data update? Do you need adding items to/removing from arrays perhaps?

[klis87]

Anyway, this might be related to #22

in order to do this, we would need to expose https://github.com/klis87/normy/blob/master/packages/normy/src/create-normalizer.ts#L167C26-L167C55 as a separate method, so only to get list of dependent queries, without manual denormalization

Anyway, it is necessary to do this only for operation on arrays, like pushing, removing, sorting. If you want to invalidate only to update properties of existing objects, you are covered automatically, no matter where those objects are and how deep. In the future I hope to also cover arrays wit #1

[jjsessa]

Before I answer, why do you need invalidation instead of in place data update? Do you need adding items to/removing from arrays perhaps?

Four main use cases for me:

1: adding and removing to lists, many layers deep. I typically can get the IDs of all the parents very trivially but would also be great if these were tracked by Normy. Add/remove list helpers could be great here also!

2: Failed mutations. I often find it easy to optimistically update mutations and refetch on failure. Saves some complexity of saving the old state to revert back to.

3. Calculated data. Think "cart total" that is driven by data of the "items" array in the cart, and there is a list view of many carts. While you can modify the cache directly, it's super convenient to just invalidate that list view,

4: peer to peer realtime updates. To save having to build a fully authenticated realtime server, it easy to just broadcast what each client changed to all other clients listening in a channel. Then the clients could just invalidate all "ids" they receive.

[klis87]

1. so yeah, in my previous message, it should work like this, normy, based on any data, can find all dependent queries, then, everything that would need to be done is refetching those found keys
2. Add automatic roolbackData #11 this might be interesting to you, this is actually something I would like to do in the near future. So basically you will get automatic revert, data to revert will be computed automatically
3. 👍
4. I am not sure, but this could be also handy for you - https://github.com/klis87/normy/tree/master/packages/normy-react-query#useQueryNormalizer-and-manual-updates-arrow_up - you get updated data inside a notification, you pass it to setNormalizedData and all dependent queries will be updated in place. Alternatively, by doing the feature with automatic invalidation we are discussing, we would refetch all dependent queries instead of in-memory updates (from example I pasted)

[jjsessa]

Re 4, I'm using react-query specifically to avoid having to build some kind of sync engine/ proper realtime service, so data over the wire is exactly what I'm trying to avoid, however it might not be as bad as I was thinking.

I was imagining a lightweight server, possibly with no authorization, that lets any client subscribe to any channel, but only receives IDs that it then needs to decide itself what to refetch. Latency is no issue here just keeping things relatively in sync within a few seconds. I currently handle this via polling.

This could definitely be a horrible approach 😂

[klis87]

Re 4, just remember, that over the wire you would need to only pass objects with ids and attrs only which were actually changed, like imagine an action like updated articles with id 1 and 2, all you need to pass is:

[{ id: 1, name: 'Updated name 1' }, { id: 2, name: 'Updated name 2' }]

then on push notification, all your queries will be updated immediately. On the contrary, if your strategy is to refetch everything, you could end up with refetching dozens of requests simultaneously, which could cause perf issues. Anyway, I would really like to have this feature built-in, as it is important to give a choice, sometimes invalidation might be just better

[jjsessa]

Agree that refetching is dangerous... invalidating is the correct thing to do here as then only active queries are refetched and other views are refetched in the background when navigating to pages that use them.

[jjsessa]

Ran across another good use case:

When doing optimistic updates you going to want to cancel all in-flight queries to avoid having your update rolled back before the mutation completes. You can probably cover 99% of cases via something along the lies of:

queryClient.cancelQueries({
  queryKey: getQueryKeysById(
    event.mutation.state.variables.id,
  ),
});

[klis87]

This is actually very interesting case, I never thought about that one.

[jjsessa]

Here is a more complete example:

If you dont mind the refetching overhead, and dont want to build out api endpoints that return mutated data, this gives you a really awesome UX as long as your passing in full normalizable objects to your mutation variables

[klis87]

This feature was added for react-query.

I will leave this issue open to add it as well to swr and rtk-query

[m10]

is the swr integration mantained at all anymore?
seems like bugs are solved for react-query only and then left open indefenitely

[klis87]

It is not my priority, because usage is extremely low in comparison to react-query and rtk-query. But it is not that bugs are not resolved, but rather some features from other addons are still waiting to be added to swr. Generally 95%+ logic is in the core, and potential bugs would leave in the core, not on addon level.

If you really care about it to be added now, I would gladly accept PR. You could see for example how it was done for react-query and do it in the same way for swr, I could happily guide you!