Recommended pattern for list-details-layout

[fnn]

Version: 3.2.0-beta.22

Hey everyone,
I'm trying to come up with a good pattern for a list-details UI (list of items on the left and details of selected item on right)

TLDR; my solution: https://codesandbox.io/embed/github/fnn/react-query-list-details-example/tree/csb-mmy1f

My problem is that the list query (['todos']) is separated from the details query (['todo', 1]) and if I mutate the selected item in the details component the same list item gets not updated.

So for simple lists I think the way to go is to invalidate the list query but if the list is a frequently changing paginated API then this could lead to weird behavior for the user (Edit one item on page 5 => invalidate list query => list completely change because you edit one item).

My solution is to use the list query only for the list order/structure and each list item would use a separated query with infinite stale time. The list fetch function sets each item to the cache. Works ok, but maybe there is a better way.

Here a CSB with the problem:
https://codesandbox.io/s/github/fnn/react-query-list-details-example

Here a CSB with my solution:
https://codesandbox.io/embed/github/fnn/react-query-list-details-example/tree/csb-mmy1f

EDIT:
Here are the changes for my solution:
https://github.com/fnn/react-query-list-details-example/compare/csb-mmy1f

[TkDodo]

You could:

• invalidate all queries that relate to the mutation:

queryClient.invalidateQueries(["todos"])
queryClient.invalidateQueries(["todo", selected])

this can even be done with one statement if you use the smart matching, but they would all have to start with the same key (e.g. todos and todos, selected:

queryClient.invalidateQueries(["todos"])

• you can manually manipulate the query cache instead of invalidating, preferably in the onMutate function, and then rollback on error / invalidate on success. see the optimistic update example in the docs.

[fnn]

What I don’t like about the invalidation is that a simple mutation can lead to a complete change of the list. The order could change, the selected item could disappear from the current page, etc. For a simple todo list I would use the invalidation, but for my real case I think it is not the best.

The manually cache update is something I will play around with.

Have you seen my attempt to use the [“todos”] query just for the list structure? If yes, what do you think about it?

Thanks for your reply!

[TkDodo]

a simple mutation can lead to a complete change of the list.

well if the state is completely different on the server-side, why not display it to the user? is it better to show a completely outdated todo list? imo, the server owns the state, and we should display it to the user as up-to-date as possible. That doesn't mean fetch like every second, but if we are updating the list anyways, why not re-fetch it? The update endpoint could for example also immediately return the actual list of all todos so that we can put them in the cache to avoid the extra fetch (see: https://react-query.tanstack.com/docs/guides/updates-from-mutation-responses)

I have seen your approach, but I don't think it is feasible for bigger applications. When the application mounts, all requests are made:

fetch Todos
fetch Todo:  1
fetch Todo:  2
fetch Todo:  3
fetch Todo:  4

even just thinking about blog posts: I have a list of 25 blog posts, the list query only returns the meta-data (title, description, author, date, tags, ...) for each entry, but the detail endpoint will return the whole written blog post, which could be potentially very large. So every time someone views the overview list, you would eagerly fetch all blog details! That doesn't sound ideal

[fnn]

well if the state is completely different on the server-side, why not display it to the user?

Yes, I totally agree. But I think there are cases were you don’t want to do this. For example, I have a paginated API, the time stamp of each item could get updates every few seconds, this will change the order of the list a lot. You are on page 2 of the pagination and you mutate an item on that page. The list gets refetched and now the item you are working on is on another page. I think in this case a good UX is to have a fixed list, but if you update the item you also apply these updates to the item in the list.

I have seen your approach, but I don't think it is feasible for bigger applications. When the application mounts, all requests are made

Sorry, I checked the sandbox and you are right. In my repository the code is different. Not sure why it is not the same. But if the ListItem query option has stale time Infinity then this is not the case. Then only the list gets fetched and the single queries are only “listening”.

Edit: I updated the CSB https://codesandbox.io/embed/github/fnn/react-query-list-details-example/tree/csb-mmy1f

[fnn]

I marked this as the answer because invalidation and/or manual updates are the general approaches for this scenario.

[sergiodxa]

This is what I do right now in production:

I have a custom hook (let's call it useArticles) to get the list to show in the sidebar, the list doesn't have all the info, only the needed to be displayed in the list (e.g. it doesn't have the whole content).

I have another custom hook (let's call it useArticle) to get a single item to show in the content area, this has the whole information including the content which can be large.

When I access I fetch the list, when the user access one of the articles I fetch that article, additionally I define initialData in the useArticle to read all the info I can from the list (titles, dates, etc.) so I can show that to the user while the content is loading (this helps to the UX).

Then, when something is updated in one of the articles I trigger a revalidation of the list and the individual article, this way the list will always be updated with that current info of each item.

[fnn]

Hey, thanks for your reply.
This is totally what I would do in 95% of all cases.

Maybe to better understand my problem:
What would you do if you would have 10000 articles in your DB and 500 people constantly updating articles. Your API has pagination. The list of articles is sort by “last updated”. You edit one article on page 5. The list gets invalidated and page 5 gets refetched. Now the article you are working on is not in the list anymore. Every article on that page changed because so many people are updating articles. So your sidebar changed completely. Hard to understand from a user perspective if the complete list changed because they edit one article.

[TechSaq]

I have similar scenario of list and deatails.
I have a listing page with infinite scrolling using useEventsInfiniteQuery hook, which uses useInfiniteQuery hook with key [{scope: 'events', entity: 'listInfinite'}]

On click of list time, event details page is opened and for this I have another hook useEventDetails with key [{scope: 'events', entity: 'details', id: 'some-guid'}]

I am editing the Event and using optimistic approach to update the event.
I am manually updating the event details query cache and it is visible but issue is coming in updating the event list cache.
I am mapping though all the events and finding the target event and return the updated event. Then setQueryData for this event list.
But I have following issues for list query cache -

1. list query cache is not updating
2. i can invalidate the list query cache but the issue is suppose after infinte scrolling I am on page 5 and if i invalidate the list query cache after upating, then how can I refetch all my 5 pages and keep the scrolling in listing when user navigates back.