optimistic update with pagination
In my task management app, I have tables for different task statuses (with sorting and filtering). Each table also has pagination (max of 50 tasks per page). Now, when I change the status of a task, I want it to update optimistically. This requires -
1. removing the task from the page where it initially was and also adding one task from the next page (if there is one) to maintain the 50 tasks in one page. Then a refetch for this page.
2. checking the currently visible page of the new status and adding the task to the page if it is meant to be on that page (based on the sort order). If it is, then I need to delete one task from that page to maintain 50 tasks in one page.
This seems pretty complex. Am I overcomplicating things in some way or this makes sense?
6 Replies
eastern-cyan•2y ago
with optimistic updates, I would only update the page that the user is currently on. So if you change a task and that makes a task disappear from the currently visible view, I would just do that.
Or do you have multiple tables / views visible at the same time?
if you are on v5, you can also use the optimistic updates that don't write to the cache, but only render differently in the view
unwilling-turquoiseOP•2y ago
Multiple status tables are visible at the same time. So if I changed the status from To-do to In Progress, it would need to be removed from To do but also added to In Progress
Structure of my query keys -
["tasks", status, pageNo, filter].eastern-cyan•2y ago
I see, yeah that's generally challenging. Maybe you can do one
setQueriesData(["tasks"], () => ... that basically updates all tasks views in one go, and then either removes the updated task if it finds it and it's not in the right filter-set, or add it if is should be in there but isn't ?unwilling-turquoiseOP•2y ago
We're also adding sort so I'd need to essentially check if a task should be added to a page or not in the optimistic update (based on the sort criteria)
That makes sense.
Was thinking I might need to do that but just wasn't sure
My main question was also around whether I am going in the right direction architecturally... If you had to implement this from scratch, would this be the way you'd do it?
I am pretty open to changing the structure of things in a way where filtering, sorting, pagination (if at all) and optimistic updates work well..
Pagination is what makes things super complicated.. I thought it is a must (since tasks could easily go into the thousands) but not sure if it is. Thoughts?
eastern-cyan•2y ago
My line is usually to avoid optimistic updates unless necessary. We're basically re-implementing the server logic on the client, which can be complicated. Of course, there are cases where the immediate instant feedback is valuable. I think your example is a good case, and a single
setQueriesData would probably be the best way to go
Pagination is fine, I would never optimistically update a page that isn't rendered though
you can pass the QueryFilter type: 'active' to setQueriesData to only match currently rendered pagesunwilling-turquoiseOP•2y ago
Makes sense! I'm thinking of maybe skipping pagination for now because of the complexity it is adding in optimistic updates. I'll add filters and sorts first. Then from there maybe add pagination once I understand what it would take? Right now I feel like I am adding too much complexity for an issue that doesn't exist (but will soon).
For our use case (and my personal desire) the instant feedback for task updates is definitely a must so this feels like a good middle ground for now.
Appreciate your advice! I will try out the implementation you suggested very soon.
Follow up questions -
I follow the order here https://tanstack.com/query/v4/docs/react/guides/optimistic-updates to do optimistic updates.
However, I'm not sure how to get all the query keys that need to be updated. I need them in order to get the previous cache so that I can pass them the the context in case of an error.
Is there a way to get all the query keys in the cache that match a filter?