Getting rid of <G: Html>

[lukechu10]

Ever since SSR has been introduced in Sycamore, one thing that has been bugging me is the <G: Html> generics on every single component. This is because the same component code needs to run in two different environments, the first one being the browser and using the DOM, the other being on the server and using a hand-rolled DOM mock specifically designed for SSR.

Current solution

The way we've been solving this issue of having two different environments is abstracting them with the GenericNode and Html traits and making everything generic over them.

This means that all the components need to have the <G: GenericNode> or <G: Html> bound on them so that they work with both the real DOM and the mocked DOM on the server.

fn MyComponent<G: Html>(cx: Scope, props: MyProps) -> View<G> {
    if G::IS_BROWSER {
        do_something();
    }
}

Advantages:

• Very flexible.
• We can mix and match DOM and SSR at the same time, i.e. we can render our view to a string in the browser (but this is a bit useless since we can use innerHTML already anyways).

Disadvantages:

• Noisy (just look at how long the component function signature is)
• Longer compile times (in theory, haven't benchmarked yet)
• Need to add the <G: Html> bound on functions that don't actually render anything, e.g. to access the G::IS_BROWSER constant.

Alternative 1: Feature flags

This is probably the most obvious solution. The idea is to have a ssr feature and a dom (and perhaps a dom-hydrate) feature to choose which rendering backend to use. Depending on which feature is activated, you can either render to a string, render to the DOM, or hydrate the existing DOM.

However, there are a few problems with this approach. Cargo feature flags are not designed to be mutually exclusive. What should we do if multiple features are enabled? For example, if both ssr and dom are set, should we do dom by default? or maybe create a compiler error? In any case, this could get pretty complicated, pretty fast.

fn MyComponent(cx: Scope, props: MyProps) -> View {
    if sycamore::IS_BROWSER {
        do_something();
    }
}

Advantages:

• No more generics!

Disadvantages:

• What do we do if multiple features are enabled?
• Testing nightmare, we will need to run our test suite multiple times with different features set.

Alternative 2: Env variables

Pretty similar to feature flag but this time using env variables instead. We could have an env variable called SYCAMORE_WEB_BACKEND which could have the values of dom, ssr, or dom-hydrate and fallback to dom if none is set.

Advantages:

• No more generics!
• No problem with mutually exclusive features (as with alternative 1)
• Prevents dependencies from accidentally adding a feature to sycamore which locks you into a specific backend.

Disadvantages:

• Changing env variables will affect codegen, which might be a bit unexpected.
• Still need to run testing suite twice (or thrice) but probably easier than with alternative 1.
• Less obvious as to how to enable ssr or hydration for the end-user. We should probably consider creating our custom build-tool similar to trunk that takes care of this, if we are to go with this option.

Alternative 3: Custom --cfg flag

Also similar to feature flags but using a custom --cfg flag passed via the command line to rustc. Essentially the same advantages and disadvantages compared to env variables because we will need to pass the --cfg via the command line anyways, except that its less unexpected when codegen changes depending on this flag.

Alternative 4: Runtime selection

Instead of choosing backend at compile-time, we could do it at runtime. To prevent shipping the SSR code to the browser when it is not needed, we could add feature flags as well, but this would simply activate/deactivate support at runtime rather than error out when multiple of them are activated.

We could, for example, define a data structure like so and implement all the methods of GenericNode on it.

enum NodeWrapper {
    #[cfg(feature = "dom")]
    Dom(DomNode),
    #[cfg(feature = "ssr")]
    Ssr(SsrNode),
}

The issue would be that we will rely on compiler optimizations to strip the ssr code out when both are enabled but only one is used.

Another issue would be how to select which implementation to use at runtime. One simple way of doing this is to just add a new context value to the reactive scope that tells us which backend to use.

Advantages:

• Very flexible.
• No generics!
• No feature flags mess

Disadvantages:

• Possible performance penalty at runtime.
• Much harder to have backend specific optimized codegen with the proc-macro since we don't know which backend we're using at compile time.
• Not clear how custom backends would work with this. Presumably, they would just completely forego NodeWrapper and instead provide their own View type instead.

[arctic-hen7]

Is it possible to get this working in some way with target-gating, such that the SSR functions are only enabled on the server-side (unless some special feature is set to enable them in the browser too) etc? We would still need feature flags or similar I would think, but using Rust's native system in this way would be a little cleaner. I'm not familiar with this part of the Sycamore code though, so I've got no clue if this is possible. I'm just going off the success I've had with target-gating basically the entire Perseus codebase, which has worked very well overall!

[lukechu10]

Yeah, we could also consider making the dom the default on wasm32-unknown-unknown and ssr everywhere else. However, the problem might be that you want to do ssr on wasm32-unknown-unknown for whatever reason, maybe because you are running on cloudflare workers which is built on server-side wasm. Especially since now that wasm is becoming more and more popular outside the browser, we might want to support this use case at some point.

Perhaps a compromise could be that we make dom default on wasm but allow it to be overridden with a feature flag (i.e. override-ssr which will force the ssr backend on all targets, even wasm). If it's not wasm, we could just default to ssr backend.

However, I don't think this would be any simpler than just making both dom and ssr opt-in via feature flags instead. This would be make it more obvious which backend is being used, rather than implicitly selecting one based on target and having to explicitly opt-out.

[arctic-hen7]

Excellent points, and, given the issue of Wasm on the server side, I agree. (Do Cloudflare workers use wasm32-unknown-unknown though? I seem to recall them having a different second part...)

[lukechu10]

Excellent points, and, given the issue of Wasm on the server side, I agree. (Do Cloudflare workers use wasm32-unknown-unknown though? I seem to recall them having a different second part...)

wasm32-unknown-unknown should work because its basically a generic target. I'm not sure if wasm32-wasi works or not.

[ghost]

These are not important details. What (i) really miss in sycamore is this:
1 - component for displaying collections with their indices
2 - reconciler for signals containing collections

[erlend-sh]

If that’s what you care about then this is not the thread for you ;)

You can open new threads for these requests (along with the use cases that motivated them) if you wanna track their development.

[ghost]

You are right. Sorry

[lukechu10]

Both are already possible, albeit with a few rough edges.

1. Just use a memo that maps your collection to one that is enumerated, i.e. my_vec.get().as_ref().clone().into_iter().enumerated().collect()
2. If you want to reconcile collections without using Indexed and Keyed (which do it automatically already), you can use map_indexed and map_keyed.

I must admit that it's a bit convoluted at the moment but should not be too hard to improve the situation given the current codebase we have.

[jafioti]

How does Dioxus currently do it? I seem to remember they just have an Element that gets returned with no generics

[lukechu10]

Dioxus uses a vdom so basically the Element abstracts over both the dom and ssr. Their components render to the vdom instead of the real dom.

[arctic-hen7]

One thing that would be really nice is to have Sycamore support using View<impl Html>, since that removes G entirely, and keeps function signatures a little more compact. Last time I checked, I believe the #[component] macro didn't handle this.

[lukechu10]

That would indeed be nice but that's unfortunately has a very different meaning from <G: Html>... View<G>. In this case, the G is basically opaque to whoever is using the component which is not good because we need to know the actual type in order to render anything with it.

[arctic-hen7]

Oh of course! Sorry, I'm an idiot.