Croct React SDK throws about client logic during SSR in our custom server rendering
We have a hand-rolled Express SSR setup (fintech, so migrating frameworks is not quick) and rendering components that use Croct hooks on the server throws the documented client-logic-during-SSR error.
What I tried so far:
- Wrapping the components in Suspense on the server. Same error.
- Conditionally skipping the provider during SSR. Then hydration mismatches.
- Catching the error in the render pipeline. Works but the slot HTML is empty
Is there a supported way to render these components server side, or is the SDK strictly client-only in a custom SSR setup?
2 answers
The React SDK's client hooks cannot run during server rendering, which is exactly what that error is telling you. The docs have a dedicated problem page for client logic during SSR, and the same constraint applies to the Vue and Hydrogen SDKs.
In a custom SSR setup you have two supported options:
- Defer the Croct-dependent subtree to the client. Render a placeholder or default markup on the server, and mount the components that use the hooks only after hydration, for example behind a mounted-state check. The slot content then swaps in on the client.
- Use a framework SDK with real server support. In Next.js, fetchContent from @croct/plug-next/server resolves content server side by design, so the personalized HTML is produced during rendering with no client swap.
For your situation, option 1 is the pragmatic path since a framework migration is off the table. Combine the deferred subtree with an initial value on useContent so the client-rendered slot has sensible content on its first paint.
Been through this with an Express SSR app. The mounted-state gate is the trick that made option 1 clean for us:
const [mounted, setMounted] = useState(false);
useEffect(() => setMounted(true), []);
if (!mounted) { return <HeroDefault />;}
return <PersonalizedHero />;Server and first client render agree on HeroDefault, so no hydration mismatch, and the personalized version appears right after mount. The one thing you cannot get rid of in this architecture is the swap itself. We lived with it for a year and eventually folded the fix into a planned Next.js migration, where the server path made the whole problem go away.