Added to this, these frameworks offer all sorts of other facilities like Dependency Injection, services for communicating with the server, etc. React only knows components. Views are implemented with components and these components contains both the logic and the markup.
In MVC frameworks the logic is separated from the markup. The controller contains the logic, and the transformation from data to HTML is usually implemented by templates. According to the React philosophy the logic and the markup are too tightly coupled to keep them separate. Because the presentation logic is not spread out over multiple objects, React components greatly facilitate reuse.
Simple & fast
Performing updates is one of the reasons User Interface code becomes so complex. As an example, consider deleting or adding a record to a list. The code needs to call the server to delete the record, but also remove or add the list from the UI. There is a lot of complex UI code for all these specialized scenarios.
Also, because the state is not centralized, you have to deal with state synchronization, which is complex and can cause bugs. It is a lot easier to just refresh the data from the server after a mutation and then re-render the whole list. React makes this especially easy by automatically re-rendering a component when its state changes. You only have to write the code that changes the state as well as the UI code that renders the result based on the state.
Normally re-rendering the UI for every change would be expensive and cause performance problems, but React has a solution for this.
DOM (Document Object Model) operations are slow. The DOM is the browser API that you can use to dynamically modify the HTML in the browser. Most of the (client-side) performance problems are caused by inefficient DOM operations. Re-rendering components after every little change is the surest way to introduce performance problems.
To solve this, React introduces a Virtual DOM. Instead of directly using the DOM, React components use this Virtual DOM. React has an event queue on the background that compares the current Virtual DOM with the previous one every n
Both on the client and on the server side
Sitecore is the content management system on top of which Mercury is built. To understand why we chose React, we provide some background information about some of Sitecore’s technical characteristics.
Everything is an item
Sitecore is mostly data oriented. When you open Sitecore’s content editor, you will see a hierarchical tree of items. Items are based on templates and templates themselves are also items. Templates define the fields that make up an item. Next to the data, an item also contains presentation details.
Presentation details determine how an item will be presented in the UI. This consists of a layout and a set of renderings. The layout defined the global HTML of the page. This layout can contain placeholders and named locations within the HTML that are containers for the renderings. A rendering contains the presentation logic that transforms a piece of data to HTML.
In figure 1 you can see a page with two renderings: FullPage
. FullPage is placed in the body placeholder. FullPage itself also contains a placeholder, namely content in which the WishList rendering is placed. When a rendering is added to the presentation details, it will optionally show a popup in which the rendering can be configured. Renderings are configurable and reusable. Now that we know how Sitecore works, let’s see why React is such a good fit.
Sitecore <3 React
React components, however, seem to have the same responsibility as a Sitecore rendering: transforming data to HTML. And in the case of React, this functionality is all grouped in a single component. This makes it a lot easier to invoke the component from within our Sitecore rendering with the data that is already available to us. As an example, in Mercury this looks like the following:
Here we invoke a specific React component that is used to display a list of recently viewed products. The first argument is the name of the React component and the second is the list of recently viewed products that should be displayed. The React component only transforms the products into an HTML representation.
In the case of Mercury, our Sitecore renderings are generally super thin and only invoke the corresponding React component. Sitecore websites are usually front-facing websites, where search engine optimization and performance are super important. With the ReactJS.NET open source project, the React components can easily be rendered on the Sitecore server. This greatly improves the initial performance of the website and fully optimizes it for search engines, despite its complex user interface.
To minimize the amount of server debugging, we develop and test the React components in the browser first. This has worked really well for us. One thing to be aware of is the Experience editor. This is the Sitecore WYSIWYG editor and is really important for the Sitecore experience. If the React component contains a lot of fields, it will not be editable in the Experience editor. Most of the times this can be solved by keeping the React components themselves as small as possible. Another thing we do is detect the editor in our MVC views and render additional fields in the Experience editor, so that they can be changed by the content editor.
Thanks to the possibility of also rendering the components on the server there is no negative impact on the SEO values of your site. Rendering the components on the server also prevents the so-called Flash of Unstyled Content, making your site performant, even on slower mobile devices. React has a steep learning curve, so we would not recommend using it if there are no explicit requirements for an interactive UI.
However, when you do need an interactive UI (do you ever not need one?) we would say React is the way to go on the Sitecore platform.