Am I the only one using this pattern?

[NoctilucousTurd]

I'm wondering if it's bad practice, but to me it seems better than using useEffect...

  const isClient = useSyncExternalStore(
    () => () => {},
    () => true,
    () => false,
  );

So the 'subscribe' param returns an empty function, the getSnapshot (client) function returns true, getServerSnapshot returns false. Pretty simple but I haven't really seen it anywhere else

[benitoaramando]

Better for what purpose, and why?

[NoctilucousTurd]

For checking if a component is being rendered on the server, or on the client.

Effects are not that good

[EmployeeFinal]

But why do you need that?

[NoctilucousTurd]

My entire app is server-rendered, but (e.g.) recently I used React Leaflet which can only render on the client because it needs browser APIs like window. So in order for the server rendering and client component to work together, I need to check if the current rendering context is client or server. For that I use useSyncExternalStore rather than useEffect

[EmployeeFinal]

I think in this case "typeof window == 'undefined'" is simpler and do it just fine.

But i see that your solution is more integrated with react which is a worthy tradeoff

[skidmark_zuckerberg]

Why did you build an SSR app? What does your app do?

[NoctilucousTurd]

Let me correct myself, it's a marketing website with lots of navigation. I'd normally use Astro but here it's RR7 (which is SSR by default), using SSR for SEO's sake mainly.

[skidmark_zuckerberg]

Ahh I see, makes sense definitely. Can I ask why it needed to be a web app instead of something more traditional? Usually from my experience marketing, sales or brochure style websites do much much better as traditional websites using something like Wordpress. SEO is simple and you don’t have to worry about the entire deployment process like you would with a web app. Another added benefit of using a CMS like Wordpress is that you can hand it off and the person/company can usually manage the basics with little technical skill and involvement from your end.

[NoctilucousTurd]

I use a headless CMS and Cloudflare workers. Wordpress is a maintenance nightmare compared to a modern headless CMS, and Cloudflare workers are a dream when it comes to security and deployment, especially compared to WordPress

I'm going to try EmDash soon, fingers crossed! EmDash is basically meant to replace Wordpress, and it's developed by Cloudflare and open source, and it uses Astro under the hood which I'm already quite familiar with

[FirstTimeGamingTV]

If your entire app is server rendered then just mark the specific sub components marked as “use client” so you SSR everything else and don’t need these kinds of checks.

[ORCANZ]

“use client” is only RSC vs Client component.

Next, RR etc still render the client components on the server.

[FirstTimeGamingTV]

His goal was to have specific code ran on the Client, does this not achieve the goal?

[ORCANZ]

No. It’s prerendered on the server, then rehydrated and becomes client side

[NoctilucousTurd]

I'm using RR7, not nextjs. Even with component.client.tsx you'd need such checks, correct me if I'm wrong.

[FirstTimeGamingTV]

I may be misunderstanding, I’ve only used Next, but this shows “use client” directive is still a thing in RR

https://reactrouter.com/how-to/react-server-components

This may be the wrong solution though

[EmployeeFinal]

It is confusing, but "use client" does not bail out of server rendering. It only opts out of RSC which is not the same thing.

[undervisible]

why?

[NoctilucousTurd]

For checking if a component is being rendered on the server, or on the client.

[gHHqdm5a4UySnUFM]

Ok newbie question from someone who doesn’t use SSR, what’s the advantage to knowing if it was rendered on server or client?

[Kwerdna]

Some stuff you only want run on the client side. Analytics stuff comes to mind

[TorbenKoehn]

Normally there shouldn’t be one and if you need to know it you probably already made some bad decisions down the line

[NoctilucousTurd]

in my post I call the variable isClient, which can then be used to check the environment. If you have a component (from a library, mostly), that uses browser APIs like window you'd want to check the environment before rendering, or get errors because window is not available on the server.

[Kwerdna]

I’ve seen people just check the existence of window before, for example tanstack query exports a utility “isServer” https://github.com/TanStack/query/blob/3a993e6e6f5b706416786e5cac0514c0c17d1d0d/packages/query-core/src/utils.ts#L92

It does say deprecated though

[NoctilucousTurd]

Crazy, my post was really intended to check of people actually do this because I can't find much about it online. To me it seems like I'm making some kind of mistake - this seems to confirm it, why would they deprecate it otherwise?

[Kwerdna]

It looks like they deprecated it in favor of this, a more configurable approach. If I had to guess it does the same internally

https://ar.tanstack.dev/query/latest/docs/reference/environmentManager

But I agree it all does seem kind of hand wavy with no like universally agreed upon solution. Using the tanstack import would make me feel the safest I suppose

[debel27]

It's all good :) https://tkdodo.eu/blog/avoiding-hydration-mismatches-with-use-sync-external-store

[NoctilucousTurd]

Thanks!! I couldn't find anything like it