Any Ideas for a universal/isomorphic app approach

[jirgn]

I'm looking forward of using react-habitat for integrating multiple react component into an cms base site. It would be really cool, if this components can be rendered serverside and initialized/registred later on. This would really help to address issues of page rendering speed as well as seo requirements. Did you already figure out a way to integrate react-habitat with ReactDomServer?

[jennasalau]

Hi jirgn,

Glad you're looking forward to using it! Let us know how you go..

As for server side rendering, that is something that hasn't come up before. You definitely have my attention! I'm just having trouble seeing what they may look like in this library.

It may have to be a small restructure of this library + a number of other server side libraries (unless we go node only?).

Is coming up with a solution something you would be interested in getting involved in?

As for ReactDomServer, react-habitat will work as expected on the client side no problem.. but as above, there has been no server side testing.

[jirgn]

Hey Jenna, thanx for the info and sorry I did not respond last time. When thinking about a proper way to do server side rendering, i come up with 3 different ideas, how how to setup.

I want the application

• to have access to the current GET-Params (i need this in my current project)
• can be configured (e.g. with a global)

To explain why, I try to give you an idea, what the scope of my current project is, and where habitat plays its role.

I build a client-side search application, that splits up in different components for

• search-result
• filter-modules
• search-bar
• ...

These components are parameterised and placed in a cms system (neos.io in my case) clean an simple with react-habitat. Furthermore the hole application needs to be configured via the cms (backendUrl, itemsPerPage ...). When initialised , the client-side app calls a Solr backend and updates asynchronously via redux + saga. Last but not least I also make use of get params so that the filter-state of the app is bookmarkable.

The first two ideas i came up with expect to run on the server like on the client with intializing the components via habitat. to make this happen i would expect habitat to have

• new factory for ReactDomServer rendering
• habitat-redux with new factory that injects the redux-state.

Idea 1

CMS delegates the page-payload to nodejs server via curl. the server (e.g. express) makes use of react-habitat to build up the full site. For an Overview see full_page.png "fullPage - CMS can not pass Data onPostRender"

pro:

• nearly same render setup as on client side

contra:

• payload/html is no template. The server-side react code must be placed into that via regex.
• cms needs to have a hook onPostRender. We also need the app-config as well as the request GET params here.

question:

• will habitat find the components on the client when no data-component attr is present anymore?

opinion:

• does not look like a promising way for implementation

Idea 2

Controller script before CMS entry point, that interprets the cms response and then delegates to a nodejs for pre-render. For an Overview see full_page.png "fullPage - CMS can pass Data onPostRender"

pro:

• this approach should work for all server-side cms's

contra:

• controllerscript can easily corrupt the routing for the cms
• complex setup
• performance may be slow
• lots of magic in the controller script cause we need to place the react code into the 'template' html like above as well as get lots of information out of the payload and interpret it for setup the serverside rendering.

opinion:

• also does not look like a promising idea, makes the above even more complicated and bases on lots of conventions

idea 3

CMS delegates modulewise to the pre-render nodejs, that renders only one component. For an Overview see module_wise.png

pro:

• should work for most cms's, cause we only need the possibility to make a curl call on module rendering or include time.
• clean api, cause the cms holds all the information and can pass the relevant info to the pre-render

service

• no implementation, changes in habitat needed

contra:

• can leed to redundant calls, if the js-app uses the same external backend endpoint in different components

opinion:

• looks like a promising approach. Also the redundant calls can be optimised in the pre-render server.

[jennasalau]

Hi jirgn,

Thanks for the incredibly detailed analysis and solution suggestions. Legend!!

We have a sizable release going out very soon (pending beta testing) and I would like to concentrate efforts on supporting server side rendering next.

Given that work on this feature will start in the near future, is this something you are interested in contributing development time too? (No pressure, just asking incase you want to be involved right through) Your pre-work certainly gives us a massive head start and I will take it to our internal team for opinions on approach.

[olafur164]

@jennasalau Has any work been put into this?

[jennasalau]

Hi @olafur164 not yet.. I'm not getting much spare time to pick something as big as this up. Feel free to tackle it if you want. Keep in mind we have lots of updates staged on the develop branch and it would be a better choice to branch from.