Suspense Query(ies) would benefit from keepPreviousData over startTransition

[jquense]

Hey team. I'd like raise that startTransition with useSuspenseQuery is generally a less useful API compared to useQuery with placeholderData: keepPreviousData, and petition to add back the ability to keep previous data while fetching without needing to wrap updates in startTransition.

The big pain point is that using startTransition requires very specific abstractions over fetching, either every consumer of a useFoo hook needs to decide how to handle all updates or state updates that triggers updates need to live very close to the fetch call site. The simple example is something like:

function usePagedTodos() {
  const [isPending, startTransition] = useTransition()
  const [page, setPage] = useState(1)
  const [filters, setFilters] = useState({})

 const result = useSuspenseQuery({
   queryKey: ['/api/todos', { filters, page }]
   queryFn: () => fetchTodos({ page, filters })
 })
 
 return {
   result,
   isPending,
   onFilter: (filters) => startTransition(setFilters(filters))
   nextPage: () => startTransition(setPage(page => page + 1))
 }
}

Behaviorally this does what I want, suspend on initial fetch, and show data while fetching the next page or updating the list filters. HOWEVER, it's really limited in the abstraction I can provide consumers. In real cases, we'd need to control and hoist filters so that a toolbar above the table showing the list can adjust the shown todos. In order to hoist this out i'd have to:

1. Move the usePagedTodos hook to a common parent.
2. Accept filters as an input usePagedTodos and tell users wrap their updates in a startTransition

The first option isn't ideal, it forces a higher suspense boundary than you might want and requires that data retrieval be done very high up vs close to the component consuming the result. The second option isn't great either b/c it's super leaky, and requires either a second utility like useTodosFilters or discipline on consumers to get behavior correct which they shouldn't have to think about. BOTH approaches conflate "filter updates" with "don't suspend" which isn't flexible or correct. I may not care if other areas of UI to suspend in response to a filter change, just not query hook.

In contrast the useQuery version of this keeps behavior configuration internal to the hook that returns the data which is i'd argue is what you want. A really nice aspect of RQ's hooks is that they are really idiomatic hooks, in that input changes trigger updates allowing for flexibly decoupled abstractions and usages. startTransition OTOH requires structuring things in terms of imperative calls to fetch, e.g. wrap and return fetchNext. There is a really nice simplicity to this example that isn't possible with suspense

[sergiidiak]

For what you described, instead of using startTransition, use useDeferredValue (tip: for query key).

Note

useDeferredValue is integrated with . If the background update caused by a new value suspends the UI, the user will not see the fallback. They will see the old deferred value until the data loads.
Usage Example

To check if the transition is pending (as there will be no fallback by Suspense boundary), compare deferred and non-deferred query key references (when finished loading, deferred and non-deferred querykeys will be ref equal)

[TkDodo]

was about to write this. useDeferredValue is a good approach here. We can't keep placeholderData: keepPreviousData because it simply doesn't work with suspense.

[jquense]

We can't keep placeholderData: keepPreviousData because it simply doesn't work with suspense.

Why is that so? it worked well enough in <= v5 and continues to work in v5 if you use useBaseQuery (I realize that's not public, merely noting that it's definitely technically possible)

I've not tried useDefferredValue here, and will give it a go. I've not gathered from previous use of it that it works like this, how can useSuspenseQuery or React know that the suspense was triggered by a change of updates starting with a deferred value?

[jquense]

thanks for the answers both of y'all btw!

[TkDodo]

Why is that so?

See e.g. this issue:

• Weird results when keepPreviousData is used with transitions #3572