In React, a component is an object that is given some properties and is expected to always render the same output to the browser from the same properties (this is key to the whole Isomorphic thing which I’ll talk about later), so as a result there is no randomizing, or logic, inside of a component.
There are some “hardcore” React developers out there who prefer to code it manually the long way, but some people enjoy pain too!
Inside each component we have a main function, which is named render(). This function is called every time that React thinks something may have changed and wants to check what the output is going to be. This rendered component isn’t directly rendered to the browser’s DOM. Instead, it’s rendered to a shadow DOM, and only the difference between the current DOM and the Virtual DOM are actioned. This results in extremely fast updates as node creations and changes are kept to an absolute minimum.
Data binding can be done either top-down, meaning that if a value changes it isn’t reflected on a parent automatically, or bottom-up. In larger applications it can be beneficial to go bottom-up, but we’ll be going top-down in the demo below, as it is simpler to learn. In this method, functions are passed into components to notify it when something gets changed.
To the following:
React.createElement("div", null, "Hello ", this.props.name);
It’s not lot of code doing it the second way, but I find I couldn’t live without JSX now! There are some “hardcore” React developers out there who prefer to code it manually the long way, but some people enjoy pain too!
If you’ve ever tried to research Flux, you’ve probably found this image:
It’s very confusing!
The basic flow is this: Components sign up to a store (think of this as a database with some local collections) to receive events when something in the store changes. If someone clicks on a button, this button then triggers an event in the “Action Creators” to do something such as “get some data”. This in turn will talk to the API asynchronously, and will then give the store the new data. Finally, the store will emit an event that new data is ready.
Isomorphic rendering is a fancy name for something which is a simple concept. It’s where both server and the browser utilize the same templates. Simple isn’t it? It’s a great concept, which we as an industry should have started utilizing sooner!
How it Works in General
How it works in .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.
npm install webpack -g
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.
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.
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.
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.