Detecting SSR/client-side

[Alxandr]

I'm doing some work on a component library, and ran across a pattern that I figured I'd ask about here. Leptos currently uses cargo-features to "detect" server/client rendering as far as I've understood. This is fine most of the time, but it causes a lot of feature-passing in cargo. For instance, libraries like leptos-use has their own ssr feature that enables/disables client/server-side functionallity.

Where this get's problematic is component-libraries like https://github.com/RustForWeb/radix where each component is it's own crate. If they need to do something only on the client for instance, you might have to add a ssr feature to all of the packages. This spreads pretty virally.

My question is basically if there is a better way to do this? I'm thinking maybe leptos could expose a const IS_SERVER: bool = cfg!(feature = ssr) or something like that. Now, obviously, this won't work for code that can't compile for the server. But I would think in a lot of cases, this simpler approach would be effectively as good as using conditional compilation.

[gbj]

I'm going to answer this question in two parts: one more specific and one more general.

Specific: I think in most cases, cargo's feature unification process means that you do not actually need to pass through features; the user setting leptos to ssr or hydrate or whatever in their final crate is sufficient.

Generally speaking the only times setting a feature is necessary in a user crate is when there is code that cannot be compiled for non-server targets, but you want to leave the possibility open for server-side WASM so can't simply use cfg(target_arch = "wasm") (or whatever the right syntax is) to gate things.

I'm always happy to discuss concrete cases but I think it's often not needed at all. For example:

If they need to do something only on the client for instance, you might have to add a ssr feature to all of the packages.

If they want to do something only on the client, they should put it in an Effect. This does not require a feature flag.

General: It is true that the way we use ssr, hydrate, etc. is bad because it features are supposed to be additive, not mutually exclusive. It is also true that many people in the last 3 years have pointed this out, and nobody has come up with a better alternative that actually works. I'm open to changing it in the future if there's a better option.

(For example, while const IS_SERVER: bool = cfg!(feature = ssr) would be fine to check "am I running on the server?" in code that can be compiled for client or server, it wouldn't work as the general approach because it wouldn't allow you to opt out of optional dependencies, ultimately leading to the mio problem)

[Alxandr]

I know, but that's because it returns a closure for unregistering. Which isn't something I'd need. I guess the other possible solution is to move all of the code after the if in my example above into an effect. Nested effects basically.

[gbj]

Fair enough. Yes, you can do nested effects. There are also other ways: for example, here's the is_server function in leptos_dom:

leptos/leptos_dom/src/helpers.rs

Lines 599 to 601 in 87fb947

	Owner::current_shared_context()
	.map(|sc| !sc.is_browser())
	.unwrap_or(false)

[Alxandr]

As of now, I made a ClientOnly::new(impl Fn()) that just calls Effect::watch with no signals to watch and sets immediate to true. I do think some sort of utility for this kind of stuff is probably something that should be easily accessible.

[gbj]

You are welcome to make a PR.

[Alxandr]

I can do that :).