Reconcile query invalidation with fresh data, selectively overwrite cache.
We are looking at a long overdue rewrite of our app, but in the interim I'm trying to make the app friendlier for updates from multiple users. The quick way - which works great - is to invalidate the cache on every update with optimistic updates (and refetch on window refocus). Problem is we are returning a lot of data every time we do this. So what I was hoping was to do an initial load for all data, and on subsequent invalidations, only send the data that has been altered since the most recent invalidation (maybe a list of id's as well, to check for deletions). But then I would like to only update the rows that have changed (or removed the ones that have been deleted). Do I want to set queryData on a successful update, instead of invalidateQueries? This is in lieu of pagination or infinite scroll, which will be a feature of the rewrite, along with more focused data fetching in general. So for example if we have a list of todos, when changing the title for one, it would only return todos whose updated_at property is after a certain date (the initial data load), but it would still keep the other todos, which haven't been updated, so don't need to change. I'm thinking about a case where one user has changed a todo title, and another user changes another title - the second user will see the first user's update.
I just need a quick QOL improvement that would reduce a user's chances of overwriting other user's data.
I just need a quick QOL improvement that would reduce a user's chances of overwriting other user's data.
