Honestly, this was the request I've seen the most about SSR frameworks: How can I stop server loaders from running on client side navigations?
@tanstack.com Start solves this with Isomorphic loaders, and it integrates with Query, too. Sooo good 🚀
@tanstack.com Start solves this with Isomorphic loaders, and it integrates with Query, too. Sooo good 🚀
Comments
Loaders *are* an isomorphic API, but absolutely not the end-all data fetching primitive. Combined with `use server`/createServerFn, you can choose if none/some/all of your loading logic runs on the server.
RR Loader = TSR Loader + Server Fn
RR ClientLoader = TSR Loader
(Full disclosure - haven't played with the beta yet, but it isn't obvious how to do that from the docs nor Adam's article)
Ended up building shallow routing for React Router as an opt-in side-effect in @nuqs.47ng.com
But I think the community is sort of missing the power of true server frameworks and the power of RSC to bridge the gap.
This reflects also reflect my needs- I didn’t use react for the web until it became more server focused.
- There's still very clear boundaries of what runs on both client+server or server-only, just as safe as Remix or Next, but a different flavor.
I’d rather leverage the full power of the server than turn the server into a dumbed down client.
you can serve cached content while you revalidate the date in background?
I find it hard to scale (code-wise and not performance-wise) when loaders are in the page loader and not close to the components.
+page.server.ts => will do only server (srr)
+page.ts => universal load (ssr then csr)
+page.svelte => your markup (can fetch)
And in DEV mode, with vite, depending on what you change you will get different path (ssr or csr).
It's good, it's fast
-> not only the page, but how you arrived to the page.
And it's often forgoten !
I think everything is valid, but you don't need everything all the time. I wish people are more aware about why like this or like that. To be intentional.
Example: a POST /comments that (a) adds the comment to the blog and (b) adds a success message to the central flash store.
I think remix handles this better than most I’ve seen.
How different is it to remix/react-router? Obviously client won’t query DB so I guess we have to define some server function for such loaders so that it calls backend to make the query (or DB directly if called from backend)?
However, might be just me, but "loader will run only on client" sounds bit confusing/incorrect. But probably it’s just me disliking possibility for misinterpretation.
Only reason I even mention this, is with wishes that no one gets confused or wrong idea and properly understands how nice it is.
- executable schema on server
- graphql request on client
Works pretty well with react-query too
The one question I have is the best way to manage cache invalidation without needing GraphQL subscriptions.
urql did a really good job of automatically refetching and invalidating a normalized cache.
When do cache invalidation issues occur?
Are you combining urql (or similar) with react-query?
- queryClient.invalidateQueries after a related mutation
- using staleTime