Tanstack/Start: options to handle client side code in a SSR world

[TheSisb]

I've been working with the new Start framework for a few days now while I love it, a painful aspect is dealing with client-side code.

In some cases, I can wrap a component (like plotly.js) with a useEffect hook like this:

  const [mounted, setMounted] = React.useState(false);
  React.useEffect(() => {
    setMounted(true);
  }, []);
   
 if (!mounted) return null;
 return <Plotly ... />

In other cases, merely importing a library causes the app to crash because that library depends on something like web workers which don't exist in Node. I'm exploring code like this to work around it:

const useClientSide = (path: string, ssrValue: any) => {
  const [module, setModule] = useState(ssrValue);

  useEffect(() => {
    import(path).then((mod) => {
      setModule(mod.default || mod);
    });
  }, []);

  return module;
};

I love the SSR and don't want to stop using it, however I feel like we can maybe make client-side less painful as well. Some ideas I had:

• Allow some setting in ssr.tsx to force client-side a component via path like: clientOnly: ['./app/components/blah.tsx', '@deck.gl/core']. This can cause layout shift, but that might be fine.
• Tap into the router to set routes that are SPA and others that are SSR. This is kinda cool with nested routes, you can get really close to the component level.
• Something like use client;? https://react.dev/reference/rsc/use-client
• (probably a bad idea) The framework can automatically shim browser features on Node to make things "just work".

Any advice or thoughts on how to deal with these issues on a per case or framework level is appreciated!

[schiller-manuel]

as of https://github.com/TanStack/router/releases/tag/v1.59.0, you can now specify ssr: false for each route you want to exclude from SSR.

[aretrace]

Is there a way to change defaults with per route opt-outs?
e.g.,
∀ routes SSR ∪ ssr: false ⅌ route
∨
∀ routes Client Only ∪ ssr: true ⅌ route

[aretrace]

Astro can selectively indicate the hydration "mode" of a component (see this).

A pseudo example for TSR would be:

<SomeComponent ssr:true />
// SSR Setting: Global config < Route level config < Component level config
// So something like <SomeComponent ssr:false /> will only make sense if 
// your Global or Route config is set to be SSR true

The syntax Astro uses is native to there own component format, so the idea I'm discussing here isn't to necessarily about replicating Astro's directive syntax in TSR, its more about the underlying principal of being able to choose SSR hydration per component.

In Next.js, one can disable SSR for a component like this:

const SomeComponent = dynamic(() => import('./some-component'), { ssr: false });

Would not really be a fan of this for SSR settings in TSR.

[schiller-manuel]

so something like ClientOnly?

https://github.com/sergiodxa/remix-utils/blob/main/src/react/client-only.tsx

[aretrace]

Interesting, content layout shift would be a problem.
I think this approach can be a good choice for TSR 👍.

(just some thoughts, a bit outside the scope of discussion)
I could also see an additional route "mode" which ensures that the route only renders once all client components (and JavaScript 🤷) have fully mounted and loaded. This "mode" could be an alternative to setting SSR fallbacks of ClientOnly utility components, this "mode" would probably be used sparsely for very niche use-cases.

[schiller-manuel]

how would astro avoid layout shift?

[aretrace]

Cumulative layout shift can be mitigated given the fallback argument from the ClientOnly utility component you just showed.
As for Astro, I am not aware of a one size fits all solution for layout shift from client only components.

[lpkobamn]

ssr: false it's very simple, thanks

[aretrace]

@schiller-manuel, would you be able to add JSDoc and API documentation for defaultSsr with a mention in the Guide? If you’re short on time, I’d be happy to help out.

[dohomi]

I'm following this conversation, does the defaultSsr prop works in a way that the whole router would be a SPA? Could this be combined with vite-plugin-pwa to have all client bundle be cached by service worker?

[schiller-manuel]

@aretrace e.g. currently the root route will always be SSRed no matter what

[aretrace]

root route will always be SSRed

ohhh 😳, I haven’t made many modifications to mine, so I didn’t notice.

full SPA mode requires additional implementation which is not done (yet)

I'm glad it's on y'all radar.

[dohomi]

@aretrace SPA mode would mean, that there is no server required for the initial request to the "/" route of your application. It basically means you can serve the HTML, JS and CSS from a CDN and only need to take care of API endpoints for server communication. For a pure admin panel which is behind a login this makes sense, especially when you want to be offline first and cache all application files with service workers

[aretrace]

Right, I didn't realize TS/Start didn't have full SPA mode (currently defaultSsr: false has been working for me so far). I'm guessing you want the TS/Router experience but with the availability of TS/Start server side functionality (or this). If that's the case, I too would like that and would agree defaultSsr: false feels like the right config for it.

[dohomi]

In my opinion a TS/start would be everything what TS/router can do + API routes. This would unify the setup for router routes and api routes. I am aware that server functions would be great too but most likely way more complicated to implement - but I think for a start the API routes would be sufficient.