ReactRender: Server Side Rendering for React Components

I actually just responded in the original repo with some thoughts on that: Some Questions + running in a release/production · Issue #44 · revelrylabs/elixir_react_render · GitHub

Here is an example of how i was able to get the node ssr process to connect back to the phoenix socket.
It only required an isomorphic WebSocket in the right place for phoenix to know how to instantiate the phoenix channel socket.

In looking closer at the phoenix source it looks like WebSocket could be passed into the phoenix socket constructor as the transport option - rather than hacking global like i did :stuck_out_tongue:

To more directly answer your question:
I think a conscious decision should be made on what data you want to have available for the SSR, and thus rendered on the server vs the data that will be fetched async once the client bootstraps.

I would also separate out the phoenix socket/channel logic from the content being server rendered via some indirection through redux or something similar. This would allow you to not include that client code when you SSR, and maybe just hydrate redux state or something on the server, and not have to worry about how it got there.

In your app.js file is where you have the socket code, and maybe add extra redux middleware to manage channel data when running in the browser vs on the the static server render.