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