{"componentChunkName":"component---src-pages-markdown-remark-fields-slug-js","path":"/engineering/understanding-react-rendering/","result":{"data":{"markdownRemark":{"id":"f135d4b5-42c2-5f4f-b0fc-9b224170ec28","excerpt":"Rendering is an essential procedure a programmer has to manage in frontend development. In React, the render() method is the only required method in a class…","html":"

Rendering is an essential procedure a programmer has to manage in frontend development. In React, the render() method is the only required method in a class component and is responsible for describing the view to be rendered to the browser window. Coupled with the clever way React operates around its virtual DOM concept, there are certain subtleties in how this method works. Understanding them will greatly benefit any aspiring React developer.

\n

Throughout this writing, I will reference this codepen for a demonstration of discussed behaviors.

\n

1. render() 101

\n

First of all, render() is not user callable. It is part of the React component lifecycle. Generally, it gets called by React at various app stages when the React component instantiates for the first time, or when there is a new update to the component state. Render does not take any arguments and returns a JSX.Element which contains the view hierarchy of the current component. This view hierarchy will later be translated into HTML and displayed in the browser window.

\n

As mentioned before, render() is not user callable as it is an event that happens in the component’s lifecycle. With that said, if it is absolutely necessary to render the view manually, you can instead call the built-in class method forceUpdate(). Keep in mind that this is considered an anti-pattern. If you were designing sensible React components, its state and props changes should naturally control the render process, and you should never feel the need to make a manual call.

\n

Within the lifecycle, these are the scenarios where render is called:

\n\n

If you have the Codepen opened at this point, before anything is rendered you will see 2 alert messages from the browser: \"render() is called in Parent component!\", and \"render() is called in Child component!\". These messages are invoked from the corresponding render() methods of the example's parent and child component. They serve to introduce the first case of render() invocation: when the component is first instantiated.

\n

Once the set of alerts is dismissed, a very simple UI will render:

\n

\"Example

\n

The dotted border line distinguishes between elements that belong to the Child component of the example (inside the dotted line) versus the Parent component.

\n\n
  onChildPropChange = () => {\n    this.setState({\n      childElementText: "I am the child element! I am updated following a prop change."\n    })\n  }
\n\n
  onTextChange = () => {\n    this.setState({\n      helloWorldMessage: "Hello React! (state change after setState call)"\n    })\n  }
\n

A visual and interactive reference to the React lifecycle can be found here.

\n

It is worth noting that following a props update or setState(), the method shouldComponentUpdate() is invoked to determine whether render() should be called. By default, this method always returns true. But it can be overloaded to implement custom logic. It is the actual way to define custom render behavior in each React component.

\n

The shouldComponentUpdate() provides you with nextProp and nextState as arguments, which allows you to compare the current state and props of the component. For example, this code block will invoke render() only when the text prop changes:

\n
  shouldComponentUpdate(nextProps: NewComponentProps, nextState: NewComponentState) {\n    if (this.props.text !== nextProps.text) {\n      return true;\n    } else {\n      return false;\n    }\n  }
\n

The characteristics and behaviors mentioned above made it imperative that render() is a pure function. That means inside render(), you should not make an update to the component's states or props (no setState() call nor Redux state update). This makes sense because an update to the component will then trigger a new render() call, which can potentially lock you into an infinite render loop.

\n

In terms of return value: render() returns a single JSX element, as mentioned above. This comes with certain implications:

\n\n

2. Notes on reconciliation, and the key prop

\n

The render() method in each React component then feeds into what is called the Reconciliation Algorithm. This is the primary algorithm that dictates how React renders the real DOM in your browser based on a virtual DOM maintained internally by React. To intelligently determine what needs to be rendered on every call, React compares the current state of the virtual DOM and the real one and only makes changes to the physical DOM where it recognizes that the UI has been updated.

\n

While not every single detail is known about React’s reconciliation algorithm, the characteristics detailed in the official documentation are enough for us to start phasing out certain suboptimal rendering patterns, thus writing a more robust render() method.

\n\n

For instance, given this DOM subtree:

\n
<div>\n  <span key="li-1">list item 1</span>\n\n  <span key="li-2">list item 2</span>\n\n  <span key="li-3">list item 3</span>\n</div>
\n

If a <NewComponent> is then added to the top of the list:

\n
<div>\n  <!-- previously <span>list item 1</span> - element is detached and <NewComponent /> instantiated -->\n  <NewComponent />\n\n  <!-- previously <span>list item 2</span> - content will be updated to "list item 1"  -->\n  <span>list item 1</span>\n\n  <!-- previously <span>list item 3</span> - content will be updated to "list item 2"  -->\n  <span>list item 2</span>\n\n  <!-- new <span>list item 3</span> is element created  -->\n  <span>list item 3</span>\n</div>
\n

If instead <NewComponent> is added to the bottom:

\n
<div>\n  <!-- previously <span>list item 1</span> - no change -->\n  <span>list item 1</span>\n\n  <!-- previously <span>list item 2</span> - no change -->\n  <span>list item 2</span>\n\n  <!-- previously <span>list item 3</span> - no change -->\n  <span>list item 3</span>\n\n  <!-- new instance of <NewComponent /> is added -->\n  <NewComponent />\n</div>
\n

In the example above, appending <NewComponent> to the end of the list will result in 1 new instantiation, versus 1 instantiation, 3 updates and 1 tear down. In a larger application scale, this will prove to be a significant performance difference in the long run.

\n\n

Coming back to the example above, let’s add keys to all the existing list items:

\n
<div>\n  <span key="li-1">list item 1</span>\n\n  <span key="li-2">list item 2</span>\n\n  <span key="li-3">list item 3</span>\n</div>
\n

In this case, if we were to add an extra “list item 4” at the top of the list, it would not come with the same performance penalty:

\n
<div>\n  <!-- new item - <span> is instantiated -->\n  <span key="li-4">list item 4</span>\n\n  <!-- matched with the old "li-1" key - element stays unchanged between renders -->\n  <span key="li-1">list item 1</span>\n\n  <!-- matched with the old "li-2" key - element stays unchanged between renders -->\n  <span key="li-2">list item 2</span>\n\n  <!-- matched with the old "li-3" key - element stays unchanged between renders -->\n  <span key="li-3">list item 3</span>\n</div>
\n

In case a subtree is generated using a map() or other iterative methods, React requires that keys are provided with the element. However, even in case a DOM subtree is manually added, keys should be provided on subtrees that have complex behaviors regarding conditional rendering.

\n

3. Parting words

\n

React is a clever framework that offers performance through its rendering scheme, so it follows that, as developers, we should leverage it appropriately to help build performant applications. With that said, it is not a miracle device that optimizes out inefficiencies from the developer’s end, but a tool to be utilized. Understanding the render() nd its implication to the reconciliation algorithm is the first step to make sure we are leveraging the framework instead of working against it. It is also one of the first steps to mastering React.

\n","headings":[{"value":"1. render() 101","depth":3},{"value":"2. Notes on reconciliation, and the key prop","depth":3},{"value":"3. Parting words","depth":3}],"fields":{"slug":"/engineering/understanding-react-rendering/"},"frontmatter":{"metatitle":null,"metadescription":null,"description":"Optimized rendering in the frontend is a crucial procedure. Let's learn how to optimize React rendering process.","title":"How to Render React with optimization","canonical":null,"date":"September 23, 2020","updated_date":null,"tags":["Node.js","React"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/56b6489418f8549fe50d61df309dd152/2ad7f/index.webp","srcSet":"/static/56b6489418f8549fe50d61df309dd152/1c9b5/index.webp 200w,\n/static/56b6489418f8549fe50d61df309dd152/f1752/index.webp 400w,\n/static/56b6489418f8549fe50d61df309dd152/2ad7f/index.webp 800w,\n/static/56b6489418f8549fe50d61df309dd152/e7405/index.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nathan Nguyen","github":"nathannguyenn","bio":"Nathan Nguyen is a Software Engineer at LoginRadius. With deep interest in creating user-facing applications, he spends a lot of his time with web and mobile technology stacks, off and on the job, looking to build applications that are ever more intuitive and helpful to end users. Loves food, travel, photography and video games.","avatar":null}}}},"pageContext":{"id":"f135d4b5-42c2-5f4f-b0fc-9b224170ec28","fields__slug":"/engineering/understanding-react-rendering/","__params":{"fields__slug":"engineering"}}},"staticQueryHashes":["1171199041","1384082988","1711371485","1753898100","2100481360","229320306","23180105","528864852"]}