React Reconciliation

Let's talk Reconciliation!

React is one of the most popular UI libraries today. It's fast, supported by facebook and not all too difficult to learn. But much like javascript, for me learning react is was more about understanding what React is doing. I haven't looked under every little nook to see what React is doing, but I try to stay semi up to date with changes, and future changes to see what direction it's going. I enjoy writing React, and it becomes even more fun when you know what's actually happening.

What I wanted to write more about and research is what exactly is Reconciliation and what does it do? Why is it important? So Reconciliation is the process in which React kind of appears to reload data or the whole app on updates, when really it doesn't. It's the API that handles what changes on every update. It's also part of the way in which React solved traversing the DOM in linear rather than exponential complexity. So if we take a look at facebook's documentation we can see they built their virtual DOM algorithm off of two assumptions to expedite this process,
Two elements of different types will produce different trees
The developer can hint at which child elements may be stable across different renders with a key prop

With these assumptions in mind, React will take it's internal built model of the DOM tree, aka virtual, and compare it with the actual DOM beginning with the two root elements.

If the root elements have different types, React will build a new tree, all of the previous DOM nodes are destroyed and components from the root level and below then will receive the lifecycle method componentWillUnmount(). Naturally, React will then build up a new tree, and components will receive what you would now expect, componentWillMount() and componentDidMount(). Also important to understand is because the DOM nodes are now destroyed and recreated, not only are those nodes gone, but also any state they were holding will be gone as well.

For example let's look at this code

//original
<div>
<Todo />
</div>

//new replaced
<p>
<Todo />
</p>

Here we originally had a Todo component nested inside of a DIV tag. Then we are replacing the div tags with paragraph tags. This is going to completely destroy and rebuild this root of the tree. This example may bring up the question of what happens when React is checking two nodes that have the same element, but the attributes are different? Well React does, in fact, check that, it will not delete the nodes in that case, but instead just update the attributes accordingly.

So if we aren't deleting DOM Nodes on recreation, what does that really mean? Well there are a number of positives to not having to recreate DOM nodes across our application, and this is what makes this process so cool, and React so fast. As mentioned earlier, when we have to delete and recreate a DOM node state that was being held at that node is now lost. Since now we are just updating the node, state is kept. So if the component is already on the page, isn't being destroyed or recreated which lifecycle methods are going to apply to this? React, under the hood, is now going to send that component componentWillReceiveProps() and componentWillUpdate(). These are both calls that are made in a component's lifecycle before the render method is called.

So things to note in reconciliation is that, the algorithm is finicky in the sense that data could persist on the page, but change DOM nodes and React may not be able to see that without the key prop, something I'm not going to get into today, but good to keep in mind when writing and optimizing your react applications. A good example of this is a list, which is on Reacts documentation where an li changes from the first child to the third child, and two nodes are added in front of it, React will re render the entire list, rather than keeping the node that still persisted. Keys get into a whole other area of what is a good key, and what isn't a good key and there are tons of articles and blog posts for that.

  //original
  <li>testing1</li>
  <li>testing2</li>

  //Full recreation
  <li>testing3</li>
  <li>testing1</li>
  <li>testing2</li>

So I hope you learned something about reconciliation today, at least what it is, so if someone brings it up in conversation you can follow along, maybe you get a better idea of when certain lifecycle methods come into play, and when to use them.