Preventing specific useSuspenseQuery hooks from running in SSR
This may have been asked before, but I'm juggling these things together:
- Code with
useSuspenseQuery tends to be more maintainable and correct than useQuery. Thinking in Suspense and ErrorBoundary seems to scale well automatically.
- We want to migrate all data fetching to suspense
- We have SSR
- Some queries weren't build with the expectation of running on the server. They depend on client-only state.
- Some queries should never run on the server. Even if possible, it's not economical due to bandwidth cost + payload size.
The only way we've found to prevent a useSuspenseQuery from running is by wrapping the component using the hook with a component that prevents it form rendering on in SSR (maybe with a fallback, but not not suspense-driven). This approach sucks in practice because:
- The call site of useSuspenseQuery and potential config there has no control of wether it will be used correctly or not.
- People forget to do add the component around the queries that aren't meant to be fetched on the server.
Me and my team struggle quite a bit with this. I feel like if we could go over fully to Suspense, then we could simplify our code a lot. But right now, we have to be really careful with useSuspenseQuery and it's way to easy to do the wrong thing.3 Replies
flat-fuchsiaOP•17h ago
I'm realizing that it might not be related to react-query after all: https://react.dev/reference/react/Suspense#providing-a-fallback-for-server-errors-and-client-only-content
<Suspense> – React
The library for web and native user interfaces
flat-fuchsiaOP•16h ago
Ended up with this thread on bsky instead after I realized the problem might be tangential. Might be interesting to someone: https://bsky.app/profile/alvar.dev/post/3m2etxnitdc2v
flat-fuchsiaOP•16h ago
I consider this thread one. Closing it.