How to use React view rendering for Sitecore, Tridion and MVC projects
At DEPT®, we’ve recently started used React View Rendering for our Sitecore, Tridion Sites and MVC projects.
Previously, the Front End (FE) team at DEPT® created a demo site using Handlebar views. This was done to allow the FE team to create the HTML and CSS without integrating in to the CME.
After the demo site was created, the Back End (BE) team took the HTML generated and integrated it into the .Net application. .Net applications can’t use handlebar views, so they need to be translated in to Razor views.
This meant that the same view had to be written in two different languages, introducing three main problems:
- additional time to manually rewrite the views;
- two places to maintain the mark-up;
- two set of views to fix bugs in
What is React?
React is a view engine used as a client side framework. It is JavaScript and has been developed by the team at Facebook.
React can also be used as a server side view renderer. For the Demo site, we use Gulp tasks to generate out HTML from the react components using the static JSON data.
React is a component-based view system, which suits our current work processes using component-based content management and design systems.
Why are we using it?
The main reason we are using React, is so that the demo and final .Net applications can use the same views. This reduces the time spent on projects converting views from one language to another.
In turn, it removes the need to translate the views, and the manual process which can introduce bugs.
Within the lifetime of a project, the demo site and integration application will not diverge. This enables all of the bug-fixing on the views to be done in a single place.
This also allows the FE team to have direct control of the views that are to be used on the site.
Using this approach allows clientside React components to also be written and integrated within the site.
How are we using it?
Within the .Net application, we use React .Net to run the react components as views from our controllers within MVC.
Passing the normal MVC model to the React view allows the .Net code to generate the model and that is then used within the JSX views.
For our Sitecore projects, we are using the Sitecore React project, which packages up the React.Net framework in a way that can be easily used in Sitecore projects.
For SDL Tridion Sites and plain MVC projects, we have forked the project and removed the Sitecore specific functionality.
A server side JS file is compiled through Webpack which contains all the dependencies and the JSX views. This is used by React.Net to render the views.
For the demo site we are using Metalsmith with the React View plugin to run a Gulp task that generates out the HTML from the JSX views. The data for the JSX views is stored in JSON files that represent the Models from the .Net Application.
Technical overview
The .Net approach is to have a new View Engine registered in the MVC framework. Within the JsxViewEngine, the CreateView method is overridden and returns a new JsxView:BuildManagerCompiledView.
The JsxView class is responsible for calling the React.Net CreateComponent Method and RenderHtml. These methods pass the incoming data to the defined JSX component. This results in a string of HTML, which is rendered to page.
Where have we used it?
We first used this process on the Sitecore implementation for Johnson Matthey, and have successfully used it on projects for Butlins (Tridion Sites) and Formula E (Sitecore). It’s worth noting that it can also be used on custom MVC builds.
By using React View Rendering, we found that there was a reduced amount of time fixing bugs. Additionally, there was a reduced amount of time spent on the initial build of the projects. Furthermore, it allows React client side components to be written in the same language.
The approach maintained the same working process we have on projects, while giving the benefits of a more integrated process. It’s proven so successful, that we’ve invested time in getting this approach embedded and tweaked for the different CMS we use as an agency.
The biggest change was around the different approach to how and when the components and their required data is defined and structured. This needs to be done before the FE build and it can’t be isolated from how the site is going to be integrated in to the CMS. This has required additional communication between the FE and BE teams to ensure the approach is the same.
For custom MVC projects, we have created a package that can be used to easily integrate react .Net in to a project. For Sitecore projects, we use this as a white label basis version.
Both use the same approach, but the Sitecore project has some specific Sitecore functionality that can be used.
This BB project is a fork of the Sitecore React project with the Sitecore specific functionality removed.
More Insights?
View all InsightsQuestions?
Architect