Understanding the server-render package


#24

OK, take this scenario:

app.com -> app.com/messages

User hits / and then routes to /messages - this all happens on the client. No problem, initial route is loaded by server, client side routing takes control after that.

app.com/messages -> app.com

User hits /messages and then routes to /. Now we have our first problem - messages was rendered by the server. This is where I’m lost - there is nothing about your code or in the meteor docs that says how to route to /messages from the server - and certainly nothing about using a different container component for that route based on what sink.request.url returns.

The next layer of my question is /messages has to show reactive data as the messages come in. If the initial container component is what provides the initial data, once the DOM is hydrated the client side stuff will take over. That data needs to be reactive though, and meteor requires withTracker to make it reactive.

So… that means the container component has to be wrapped with withTracker which basically is breaking routing.

I am super appreciative of your time and help here, it’s informing a big business decision right now over what to use for our next application.


#25

on app.com/messages sink.request.url will app.com/messages as well.

so <StaticRouter location={sink.request.url}> will make ReactRouter render every <Route /> that matchs that location. (and also every data-fetching-component that are wrapped in these routes).

So when a user hits app.com/messages (means as initial route), the server will render the app as it would be in that route.

The next layer of my question is /messages has to show reactive data as the messages come in. If the initial container component is what provides the initial data, once the DOM is hydrated the client side stuff will take over. That data needs to be reactive though, and meteor requires withTracker to make it reactive.

hydrating means that the client code will run and react will re-use the markup. Apart from that, everything else will be like there would be no server rendering. Subscriptions will start, collections will fill with data and withTracker-containers will update if new messages arrive.

So… that means the container component has to be wrapped with withTracker which basically is breaking routing.

The router does not care what your components do. It just mounts the components that match your route.

The important question is now: have you tried it out? what does not work like you expected?

I am super appreciative of your time and help here

you’re welcome. and sorry to sound harsh, the language barrier and limited time makes it a bit harder to find the right words.

it’s informing a big business decision right now over what to use for our next application.

One thing to consider: SSR with meteor’s older pub/sub-mechanism works, but it’s not so common anymore and finding tutorials, help and tools is becoming harder. Pub/sub got displaced by graphql (apollo) and you will find much more resources for that.


#26

This thread really proves the need for the Meteor guide to have a Server Side Rendering section for React apps

If anyone has some spare time to summarise the info in this thread, it would be very much appreciated: https://github.com/meteor/guide/blob/master/content/react.md


#27

If it’s helpful, I have a starter here which does SSR:


#28

Thank you @macrozone for your patience.


#29

@coagmano agreed. you have parts of the documentation dealing with making react components reactive which make you think everything has to be wrapped in withTracker and then you go to SSR portion of react and you get … a couple paragraphs.

I’d love to update that, but I still need to figure it out haha.