@Ephem one open question that came to my mind today is how this would integrate with the planned experimental_prefetchInRender flag combined with the React.use() operator. I don't think we can warn here as well when the prefetchInRender fires a fetch, as it would make the whole feature obsolete: If you have a running promise already, you will never need to fetch-in-render...

Excited that RQ is thinking about this! We've been working on our own enforcement of this on top but it'd be nice to have it built in.

One concern with the Context provider approach is that it makes it harder to do incremental migrations of existing code. In our experience you rarely have nice and neat "clear" branches of the app you can cordon off to enforce prefetching in. In practice we pull up queries one at a time as we have time to track down requests in component trees and refactor fetching logic out of hooks so they can be prefetched by the router. This can take some time before we can say "don't allow fetching in render here".

One option is to have something like usePrefetchedQuer(y|ies) (or query option) that marks individual call sites as always expecting data for the under prefetching cases.

Will there be support for regular useQuery? It might not create as bad waterfalls as useSuspenseQuery but it still makes a difference when data is prefetched in route loaders, especially with lazy loading. There could be an option for that as some queries might be non-prefetchable for various reasons.

Just wanted to clarify that on over-fetching, this:

Whenever a Query isn’t used within a given time frame (probably 5ish seconds?) after it has been prefetched...

wherein you say "after it has been prefetched" means this (configurable?) timer is only started once the cache has been populated with the prefetched data, not started from when the query is started, correct?

Just calling useSuspenseQuery in your component and having it work is very convenient, but without a compiler like relay, it won’t be possible to extract those data requirements and trigger prefetching somewhere else automatically.

I don't really have anything to add to the <QueryStrictMode> discussion here. It seems fine, but what is stopping React Query from adding a compiler to automatically hoist and prefetch data? Admittedly, graphql does lend itself very well to the whole idea of defining fragments in your component and having a compiler statically extract that into queries higher up the component tree. It also helps that Relay is only scoped to graphql whereas React Query is really just an async data loader.

If at all possible, would you be able to provide some details why adding a compiler to React Query would be a bad idea or wouldn't work? I really don't know what it would look like but it would be valuable knowing more details beyond the quoted statement above.

Yes, without a compiler this all gets tricky and validation moves to runtime. But, why can't React Query introduce a compiler?

This might be only tangentially related but I wanted to share a use case we've run into that might be relevant.

We have certain pieces of data that are only fetchable on the server, ie. there is no corresponding client-accessible API to fetch them from the client. We fit this into our existing React Query data setup by defining a useSuspenseQuery call that looks for a given query key, but does not provide any queryFn. We then make sure to "prefetch" that query on the server so that the data is always available on the client. This works as long as the prefetching is working properly, but we've run into cases where we get a "Missing queryFn" error because the prefetched data wasn't there, or was garbage collected or something. In order to prevent that we have to make sure that React Query never removes or tries to refetch the data by setting staletime and gc time to infinity.

I wonder if it would make sense in a strict prefetching tree to change the behaviour of a useSuspenseQuery that lacks a queryFn, so that it automatically preserves its data forever and never attempts to call the missing queryFn, just logging an error if the data is not prefetched already.

Unsure if this falls under the same problem you are trying to solve, but if we do list.prefetchInfinite() and combine it with list.useSuspenseQuery() it will cause loading / suspense to flicker twice. Changing to list.useSuspenseInfiniteQuery() resolves the issue.

Basically enforce a warning to match proper prefetch with proper useSuspense.

Syntax written above is from tRPC.

I really like this RFC, and I can't think of a better way to implement it, as you said there is only one trade-off we're left with...

One issue might be, when you want to mix some hoisted requirements (ensure prefetching for some things), while letting some Suspense boundary intentionally in place, and that would then be throwing the warning even though it is not useful. The proposed #8064 (reply in thread) and the counter-argument is valid, so I get why we'd want to use a top-level <QueryStrictMode>, perhaps the way to "silence" the known waterfalls is to use a hook that preceeds the upcoming useSuspenseQuery() (that would trigger a waterfall):

useMuteQueryStrictMode(todoOptions)

This way it would be co-located, can be a noop for non-DEV and can still issue a specific type for the logger, like known-missing-prefetch for instance.