This document discusses server rendering for isomorphic React web apps. It explains that server rendering allows search engines to crawl single page apps by pre-rendering content on the server. This involves using React.renderToString to generate HTML on the server and then hydrating the app on the client with React.render. It also recommends designing URLs first, using common libraries for both client and server, and addressing differences between synchronous server rendering and asynchronous client fetching.
6. “Yak shaving is what you are doing when
you're doing some stupid, fiddly little task
that bears no obvious relationship to what
you're supposed to be working on, but yet a
chain of twelve causal relations links what
you're doing to the original meta-task.”
- Jeremy H. Brown. http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-
11.html
8. ● Design your URLs first, they are important.
● Choose libraries that work in node and the
browser
● Use CommonJS and a module bundler
Core Architecture
9. Fetching data is typically an
asynchronous process.
React.renderToString is a
synchronous process.
“Isomorphic” - fancy way of saying that a javascript application can run on the client or server to render.
React is currently the only js framework with server side rendering baked in as a core feature.
(Ember.js fastboot is still in development, AirBnB has moved away from Rendr to React.)
React server rendering allows us to create crawlable web apps while undoing years of hacks due to technology mismatches between the browser and the server.
Allows us to take advantage of deferring as much as possible at page load since the content is already rendered.
Googlebot translates the hash url to a querystring to request page state.
Expected that the server will render the client app and send back the rendered markup.
Businesses spun up around this: prerender.io, brombone
This is a lot of extra infrastructure.
No explicit documentation yet about how much javascript the googlebot executes, how long it will wait for async operations, etc.
SEO with static html has much more existing knowledge and research already available, and is what all search engines do by default.
Prerender can introduce significant latency into the rendering process.
Caching prerendered pages solves the latency problem, but introduces potential for stale content.
Managing caches and cache expiry introduces lots of complexity.
Time spent setting up a prerender process is time not spent working on your actual application.
Allows us to go back to how web apps have always worked, without having a technology split that requires duplicating code on the client and server.
Both browserify and webpack have good solutions for bundling React and integrating with react-tools for jsx transformation.
Choose which ever tool you’re most comfortable with.
You don’t necessarily need to use a router with React, but it will help.
You must gather all necessary data before rendering app.
Easiest way to keep this simple is to have skinny route handlers, fat services.
If using a Flux library just requires prepopulating your Stores with the proper data before calling React.renderToString.
