@theefer @OliverJAsh I’ll respond more at my keyboard, but the simple solution to this is to adopt invalidation patterns over manual data normalization. Just invalidate all of the queries. They already know how to fetch the exact data they need.
@theefer @OliverJAsh Regardless of React Query or not, normalized caches on the front-end come with the upside of fetching less data and using the responses of mutations as much as possible. When you like a tweet, you just go find that tweet in your store and update it
...
...
@theefer @OliverJAsh This situation works fine if that action doesn't have any side effects on the rest of the system. Imagine tweet deck that is showing only liked tweets, or a list that is sorted by time of liking. This now means that you either have to replicate all of the logic on your server
..
..
@theefer @OliverJAsh that is responsible for sorting, filtering, ordering, and all permutations of data views being served to the client. You have to not only know about all of the possible side-effects of your normalized update, but how they would affect data views coming from the server as well.
@theefer @OliverJAsh The other side of the spectrum is doing very little or no normalization and instead relying on the server as the source of truth for side-effects. When a tweet is liked, you simply invalidate all queries that potentially depend on that tweet. They refetch in the background and...
@theefer @OliverJAsh you "sync" up with the server. The upside here is you no longer have to worry about implementing side-effects on the client, and the downside is potentially overfetching data. However, if this potential is too great, then you could also say that the user reloading your app is...
@theefer @OliverJAsh Also too great, because the latter would be even worse in terms of bandwidth and perf. What RQ does is gives you the tools to do highly selective synchronization of queries from server to client all in the background. So depending on the speed of your API...
@theefer @OliverJAsh You might have a split second where other instances of the tweet are not "liked", but they will be eventually, along with any and all server side-effects that you couldn't have known about. But it doesn't stop there...
@theefer @OliverJAsh You can then gracefully opt in to optimistic updates. This is basically invalidation++, where you're still invalidating and synchronizing with the server, but after (or better yet before) your "like" mutation is executed, you can optimistically update any high-priority areas...
@theefer @OliverJAsh of your application that the tweet may be displayed. This may sound like a lot, but its probably just 1 or 2 places, or better yet a known list of queries that you can loop over and update in one swoop. So now, your tweet will immediately be "liked" on the client everywhere it...
@theefer @OliverJAsh counts, but then you ultimately fall back on the invalidation (or synchronization) that happens for all of the relevant queries, including ones that have your single tweet in them. This ensures true eventual consistency with the server while being as optimistic as possible.
