Simple & fast
Performing updates is one of the reason User Interface code gets so complex. For example, 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 scenario’s. Also, because the state in multiple places, 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 and only have to create the UI code that renders 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.
Both on the client and on the server
Sitecore is the content management system on top of which Mercury is build. Read more about Sitecore here. To understand why we chose React, I will 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.
The presentation details make up 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. Placeholders are 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 & Wishlist. 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. So renderings are configurable and reusable. Now we know a bit of how Sitecore works, let’s see why React is such a good fit for this.
Sitecore <3 React
React components however, seem to have the same responsibility as a Sitecore rendering: transforming data to HTML. And in case of React, this functionality is all grouped in a single component. Making 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.