Implementation

How it Works in General

The templates are pre-rendered on the server, and are then injected into the HTML response of the page. This also includes a copy of the dynamic properties which were used to render the page so they can run in the browser and get the same output. This means that whilst the browser is loading its JavaScript assets, HTML has already been rendered before the onDomReady event has fired, whereas with normal client-side rendering (Angular et.al.) even after the onDomReady event, it still has to render the templates and maybe get some data!

How it works in .Net

In the Node world they can execute the templates (which are simply Javascript) on the server with issues as they are already running a JavaScript engine.

For .NET to run these templates on the server, we’re going to have to run a JavaScript engine too! Don’t worry, this isn’t as bad as you thought! There are two .NET builds specifically for React: the Offical React.Net and Offroadcode’s very own SuperchargedReact.Net.

The official implementation keeps a pool of engines in memory, which could be one of several types (MSIE, Jint, and v8 from clearscript).

SuperchargedReact.Net has a different approach. We only use clearscripts v8 (let’s just agree that v8 is the best) and instead of pooling the engines, it uses a single engine but with several contexts on the same engine. This reduces memory consumption.

How it works in Umbraco

Umbraco very much wants to be in control of the templates, so we use route Hi-jacking to create models which either return rendered HTML through React , or JSON if it’s an AJAX request (such as the client requires more data). I've setup document types which all use the same razor template, this results in razor being in charge of the rendering.

Seeing it in action: A Supercharged demo

I've prepared a demo which includes a compiled bundle of the component. It has been made to be runnable from within Visual Studio. Simply open the solution and then run it.

Compiling

Once you have it running locally, you can (although it isn’t needed) compile the JavaScript yourself. You will need to have React installed and then install the packages, by running “npm install” from the command line. Doing so will install React and the boilerplate components I’ve installed, such as the routing engine.

Next you will need to build the JavaScript into a bundle file. I’ve chosen Webpack for this, you can install by running:

npm install webpack -g

This will install globally, you may need to reopen your console after this, then it’s a simple case of running “webpack -- watch” and your javascript files will be compiled into the bundle when changes are detected.

NPM is package manager that is similar to .NET’s NuGet. It comes installed when you install NodeJs. You’ll find the following NPM commands useful:

npm install – this will install all the which are required by the project

npm install <packagename> --save will install a package as a dependency and save it to the package manifest file.

React Structure

The entry point into our JavaScript is in the file ~/Assets/JS/app.jsx. This file is where the application is kicked off from, it’s here we load our routes into Javascript (which are stored in ~/Assets/JS/routes.jsx) also initiate our Article store.

Article Listing

For the listing page, we have two components: a list and a list item these are stored in ~/Assets/JS/components/ArticleFolder.jsx. Some React occurs in the ArticleItem component on the link to a specific article. This <Link> element is built into the router system which I’ve installed, and this module will introduce an <a> element into the DOM, so even if the client hasn’t got JavaScript enabled the link will cause a standard request to the server, meaning the site will degrade gracefully.

Once the Article component is loaded, it will render once with the data which has from the article store, and it will make a request to the server for the complete data for the rest of the article. Once the store has this complete data, it re-renders the page and replaces what’s changed with the updates.

Recap

The flow of a React request looks like this:

Umbraco matches url to content

Umbraco Route hijacking does the logic to get the view model

Umbraco renders the React Serverside Template with the viewmodel

React kicks off on the server and renders the template

React’s rendered HTML and the viewmodel are sent in the response HTML

React is started on the client and verifies the displayed HTML.

Conclusion

I would use React on a large site where there are lots of interactions that go on with the user, but not on a smaller site as the benefits of Isomorphic rendering wouldn't substantial enough to overcome the larger development costs.