Support for static rendering about sycamore

[lukechu10]

Thanks for bringing this up. Definitely something I plan to support. Probably a good idea to get a working prototype of this early on to not have worries later.

[arctic-hen7]

I feel it's worth mentioning that Perseus is a framework based on Sycamore that supports SSG fully, including using it with SSR (with state amalgamation).

[lights0123]

This will exist soon in #67.

[philip-peterson]

That's great news. If you need a server-side DOM for static rendering, although it's not really done yet, I've been working on https://github.com/philip-peterson/rust-rdom which is a Rust implementation of at least some of the WhatWG DOM spec. I could use help if anyone's interested in collaborating. The more the merrier!

[lukechu10]

There is a prototype of rendering template! to a string in #67 (thanks for all the work @lights0123!). One problem we have now is related to API ergonomics. To support SSR and DOM, we need to compile a different version of the component depending on the context.

Since maple doesn't have a VDOM and doesn't plan to have one, an option would be to make TemplateResult generic, excepting a type param G which determines which backend to use (DomNode or SsrNode). Pros for this include more flexibility in which backends are used. We could render a TemplateResult to a string on the client as well if we wanted to. Cons mean that we would need to add a type param to every component.

The alternate route would be to use feature flags that determine which backend TemplateResult will use. This makes it slightly less flexible in that only one backend can be used at a time. However, I don't really see this as a problem because this use case would be extremely rare (in fact, I cannot think of a single use case where having multiple rendering backends would be useful and to my knowledge, most frameworks/libraries do not support this, e.g. svelte either compiles for dom or ssr but not both).
I do not think enabling this niche use case outweighs penalizing everybody else who doesn't need it.

However, there is a workaround for the first possibility. We could recommend creating a new type alias

type Template = TemplateResult<DomNode>

for users who don't need SSR. For those who do, they could add a cargo feature on their crate (called ssr) and have the following code:

#[cfg(feature = "ssr")]
type Template = Template<SsrNode>;
#[cfg(not(feature = "ssr"))]
type Template = Template<DomNode>;

but then, we're back to the feature flag idea.

Another thing to think about is potentially supporting more rendering backends in the future (e.g. native, gl, etc...). In this case, we might bump into problems with the second approach because maple-core would not have access to rendering backends defined externally.

A last possibility would be to create a GenericNode data structure which would have .to_dom_node() and .to_static_string() which would create the DomNodes and SsrNodes on demand. The problem with this is potential lifetime problems as well as an extra layer of indirection.

Any ideas/opinions on this?

[fimbault]

Well, it could be useful to support both cases at runtime. See vercel/next.js#19606 as an example, or similar requirements (ex a serverless middleware in nextjs).

[lukechu10]

Well, it could be useful to support both cases at runtime. See vercel/next.js#19606 as an example, or similar requirements (ex a serverless middleware in nextjs).

Yes that is how it works right now. If you look at https://sycamore-rs.netlify.app/docs/basics/components, you'll see that in the next version, you need a #[component] attribute macro.