Server side rendering?

[leeola]

Just curious about SSR and where Valerie stands on it. I imagine it's not possible now, but would it require massive changes to make it possible? Would work towards SSR be in line with the project goals?

[emmanuelantony2000]

SSR is one of the main project goals. And major refactoring to the codebase won't be required for that. I need some opinions.

[Zizico2]

I think it'd be an awesome feature, not only for traditional ssr, but it'd open the door for a static site generator. I tend to just prefer pre rendering over ssr

[VizorKit]

I would prefer using hypermedia as my ui driver over server side rendering. Something like HAL or Siren. The benefits are your backend can still be an api that is walk-able across entities, but you can also get all the details on how the structure of your entities should be presented to a user agent.

[emmanuelantony2000]

Currently the plan is to bring the HTML part of the library to maybe something like the stpl library, then we can have proper types for Tags, so we can serialize and deserialize them and pass the UI directly from the server to the client. Now the client can have a StateUI or something like that so that when it receives an update from the server it updates the UI automatically.

[VizorKit]

Could you draw this plan up in a diagram? I'm not sure I'm following. But from experience. You don't actually want server side rendering. For a multitude of reasons. This document published by google discusses limitations pros and cons of what you are proposing. Rendering on the web.

There are numerous political reasons if you make SSR or static site generation your main goal, you lose out on tons of potential users. I would like walkable api's. at the same time, I would like to be able to consume those api's from the front end, and my customers would like to be able to use the api's as a selling point when doing b2b.

Do what you will, but I saw your blog post, and thought thats exactly how easy it should be to make html and client side wasm, which is what I assumed you would be doing. Then SSR or static site generation is just a matter of implementation, not a whole locked in framework.

[emmanuelantony2000]

Do you mind if we can continue this conversation in Discord?? @VizorKit

https://discord.gg/xx2sArF

[Zizico2]

After further discussion on the Discord server we have reached a possible StateUI.

It'd be a component that subscribes to state variables and requests new UI from a server every times those variables change, informing the server of the new values. StateUI could then be used as any other void (or empty) component, like Br, Img, etc.

The state variables and the resource's url would be passed as attributes. The way to pass attributes to components is still not finalized (#2), but for now this is where we are at:

Client side:

fn ui() -> Node {
    let name = StateMutex::new(String::from("Andrew"));
    let age = StateAtomic::new(5usize);

    div!(
        // Some UI...
        StateUI::new()
            .url("127.0.0.1:800/age")
            .state_var(("name", name))
            .state_var(("age", age)),
        // Some UI...
    ).into()
}

Server side:

// Some code...

let res = serialize(
            div!(
                h1!(name),
                h2!(age),
            ).into());

res.send().await?;

// Some code...

We need some opinions.