Using leptos for only ssr without hydration

[Blechlawine]

I want to use leptos only as an html rendering library on the server, with the view! and component macros. Its been working great so far, but the problem i've run into is: when i make a component which takes a reference to some type and give it a lifetime bound to component function, it works sometimes, but other times i get an error that the lifetime of that reference must outlive 'static. I think this is is probably because on the client the component/view lives longer than the actual rendering cycle, but it doesn't do that when i'm only rendering to a string on the server and then sending that string away. The error goes away when i set the component to return a String instead of impl IntoView and call .to_html() on the view but then i'm allocating a new string for every instance of the component, even if the instances are all on the same page, right? is there a way where i can still use the full power of components and the view macro, but not get errors that references must outlive 'static and without returning a string from every component?

In an ideal world i'd imagine an optional feature on the leptos crate only-ssr which generates code optimized for rendering on the server without the lifetimes required for reactivity. Ideally even without allocating a String to send to the client but sending the rendered result as a stream? (i don't know if this last part would be possible)

[gbj]

In general, many of the built-in control-flow components do require 'static bound for a variety of reasons, including both client-side rendering and support for async rendering on the server. If you don't need either of these, then yes, the requirement is stricter than it would need to be if you were designing an HTML templating library from scratch that only supported synchronous, server side rendering without the other pieces.

It is not plausible for us to toggle the lifetime bounds on or off — even if it were even possible (it may or may not be, I am not sure!) it would create a bunch of maintenance overhead for quite a niche feature.

In general, you can use borrowed data for component props—this compiles, for example

use leptos::prelude::*;

fn main() {
    let something = String::from("test");
    let html = view! {
        <Foo input=&something/>
    }
    .to_html();
    println!("html = {html}");
}

#[component]
pub fn Foo<'a>(input: &'a str) -> impl IntoView {
    view! {
        <p>{input}</p>
    }
}

I'm happy to try to help debug other examples, if you have concrete cases that have errors. But in general it will almost certainly not be a big deal to take owned data in those cases.