Handling client side sorting of cached data

[ssteuteville]

Hi guys, fairly new react-query user here and still trying to wrap my head around the different patterns I'm going to need in my toolset to get the job done.

Currently, we are migrating a feature from redux/saga which involves a drag and drop. The order of the items after some dragging and dropping has occurred is not persisted to the server, instead, the order is used one time on the next step of the user's workflow. So I don't think a mutation/invalidation makes sense, and manually modifying the cache feels hacky unless it's in an optimistic update. Storing the records I'm sorting in UI state and sorting them there also feels wrong because then I'd have two copies of data in my server cache.

What would be the "idiomatic" way to handle this situation?

[TkDodo]

It's an interesting case for sure. I would usually advice to keep server state and client state separately, and don't move server state into local state:

const { data } = useQuery('key', fetchFn)

{ data && <MySortableComponent initialData={data} /> }

function MySortableComponent = ({ initialData }) => {
   const [sortedData, setSortedData] = React.useStatate(initialData)
}

The problem with this approach is that this completely ignores background re-fetches that react-query might do (refetchOnWindowFocus etc). If you want to ignore them for this use-case, you can turn them off via the settings and use this approach.

Modifying the cache, as you mentioned, is not good because it will also be overridden by background re-fetches.

I mostly try the following approach, even though I don't know how this would combine with sorting:

• always respect the data from react-query
• user input always takes precedence over background refetches
• don't sync server state and client state with effects
• compute the result that you display to the user on the fly based on the user input and the server data

This works very well if you for example use the data from react-query to pre-fill a form, but the user can change the values. If you re-fetch in the background, only the fields that the user hasn't touched will be updated.

But for sorting, this seems very hard to do, because what should happen if items are added / removed on the server and you receive that update while the user is sorting...

Storing the records I'm sorting in UI state and sorting them there also feels wrong because then I'd have two copies of data in my server cache.

I don't quite get that - why would you have two copies in the server cache ? You would have one copy in the query-cache and another copy for sorting in local state (like in my above example).

[ssteuteville]

I don't quite get that - why would you have two copies in the server cache ? You would have one copy in the query-cache and another copy for sorting in local state (like in my above example).

Sorry I phrased that poorly, I meant "I'd have two copies of data that is in my server cache" One copy in UI state, the other in cache.

Everything you said makes me think I do not have an issue with how I'm thinking about the problem, you agreed with most of my concerns. That list you gave me is awesome, I'll be pushing that to the rest of my team!

In terms of this problem, we came to a different approach:
Instead of storing the data in UI state, we just stored the order in UI state, based on the id of the record.

const [recordOrder, setRecordOrder] = useState<number[] | undefined>();

When a re-order happens, we set that local UI state to reflect the user's input. Then we use the recordOrder to sort the data that came from cache.

One reason this worked was that when refetches occur we have ways to add new records to the order and ways to remove old records for the order without impacting UX.

[TkDodo]

Instead of storing the data in UI state, we just stored the order in UI state, based on the id of the record.

that is really cool, it's basically what I meant: separating the server state and only storing the user input / selection in the the client state (recordOrder), and then sort the serverData with the stored recoredOrder.

Glad that you could make that happen for your use-case 👍