server-side-rendering about mercury HOT 10 CLOSED

@RnbWd there is a branch for server side rendering ( https://github.com/Raynos/mercury/tree/server-rendering ).

It's still a work in progress.

There are three things that need to be implemented

• remove hooks & widgets server-side since we can't turn them into HTML. Alternatively implement a toHtmlString(vtree) function.
• test / use / implement https://github.com/marcelklehr/vdom-virtualize to turn a server side rendered HTML tree into a vtree.
• deal with the transient state problem.

Server side rendering

The way you do server side rendering is as follows

• Write a function render that takes a data object (plain JS object) and returns a vtree (probably by using h()
• convert it to a HTML string properly (replace widgets with <span>)
• server side render the HTML. Ensure you embed the data object used to render() on the server in the pay load
• in the browser get the data object and call render() on the client to get a clientVtree (one with widgets & hooks)
• virtualize the server side rendered HTML into a serverVtree then just patch(container, diff(serverVtree, clientVtree))
• now you are done.

We probably need to update main-loop to be sensitive to these new concerns. Especially virtualize

The transient state problem

If you have something like h('input', { value: state.value, 'ev-change': state.events.change }) in your render() and you server side render it, you run into a problem where a user may enter text in an input before the change event handler is added (i.e. interacts with the page whilst the page is loading)

The main solution is calling render(state) on the client side twice, the first time to build a vtree and parse out all event handlers, we then trigger the event handlers with the current state of the DOM elements if the state is non-empty, i.e. basically replaying DOM events that fired before javascript was loaded

The second time we render() the state should be different, i.e. updated to be correct because events have been replayed, we can then continue as normal.

If we don't do this then client side rendering will overwrite your current input element with an empty string.

from mercury.

@alexmingoia started working on https://github.com/alexmingoia/virtual-dom-stringify/ to solve the string problem

from mercury.

Excellent, I'll look into it and see if I can help with anything :)

I tried going through the React source last week to figure out how they do it.. no luck. Separating event handlers before converting to string would provide a basic implementation. The transient state problem is hard to solve, but if the js renders fast enough it might not be the worst. Thanks for helping out and working on this project, I think it has lots of potential and I'm using some of the modules for other projects already.

from mercury.

@RnbWd no worries, it's super cool to see you using observ-* and react together in the wild :)

from mercury.

@RnbWd I merged a server side rendering example.

it does the virtualize & to html string parts.

it doesnt deal with the transient state problem, but that's a seperate "bonus" problem that can be solved seperately.

Any further work on this problem should be fixing bugs in vdom-virtualize and virtual-dom-stringify

from mercury.

@Raynos , Thanks for updating the example. IMO the transient state problem isn't a big deal (from the user perspective). How much can you do between the initial HTML render and when scripts load? I'd like to find time to help test / contribute to this project, I really like where its going :)

from mercury.

Just tried it out, looks really good!!

from mercury.

It's still a work in progress.

is it ready now? I've seen a render function here, is it the toHtmlString(vtree) you are talking about?

from mercury.

@cauburtin server-side rendering kind of works.

It's definitely possible, it needs a little bit of boilerplate in your app, you can see the example

from mercury.

Thanks, I'm going to deal with isomorphic code (necessary in that case -SEO)). I guess the difficulty is for events inside that tree? A tree without event handlers inside is maybe not hard to stringify

from mercury.