Step Zero: Review

But first let’s review some basic concepts. You can skip this step if you already have a good idea of how React, JSX and DOM elements work.

We’ll use this React app, just three lines of code. The first one defines a React element. The next one gets a node from the DOM. The last one renders the React element into the container.

Let’s remove all the React specific code and replace it with vanilla JavaScript.

On the first line we have the element, defined with JSX. It isn’t even valid JavaScript, so in order to replace it with vanilla JS, first we need to replace it with valid JS.

JSX is transformed to JS by build tools like Babel. The transformation is usually simple: replace the code inside the tags with a call tocreateElement, passing the tag name, the props and the children as parameters.

React.createElement creates an object from its arguments. Besides some validations, that’s all it does. So we can safely replace the function call with its output.

And this is what an element is, an object with two properties:type andprops (well,it has more, but we only care about these two).

Thetype is a string that specifies the type of the DOM node we want to create, it’s thetagName you pass todocument.createElement when you want to create an HTML element. It can also be a function, but we’ll leave that for Step VII.

props is another object, it has all the keys and values from the JSX attributes. It also has a special property:children.

children in this case is a string, but it’s usually an array with more elements. That’s why elements are also trees.

The other piece of React code we need to replace is the call toReactDOM.render.

render is where React changes the DOM, so let’s do the updates ourselves.

First we create a node* using the elementtype, in this caseh1.

Then we assign all the elementprops to that node. Here it’s just the title.

* To avoid confusion, I’ll use “element” to refer to React elements and “node” for DOM elements.

Then we create the nodes for the children. We only have a string as a child so we create a text node.

UsingtextNode instead of settinginnerText will allow us to treat all elements in the same way later. Note also how we set thenodeValue like we did it with theh1 title, it’s almost as if the string hadprops: {nodeValue: "hello"}.

Finally, we append thetextNode to theh1 and theh1 to thecontainer.

And now we have the same app as before, but without using React.

Step I: ThecreateElement Function

Let’s start again with another app. This time we’ll replace React code with our own version of React.

We’ll start by writing our owncreateElement.

Let’s transform the JSX to JS so we can see thecreateElement calls.

As we saw in the previous step, an element is an object withtype andprops. The only thing that our function needs to do is create that object.

We use thespread operator for theprops and therest parameter syntax for thechildren, this way thechildren prop will always be an array.

{
"type":"div",
"props":{"children":[]}
}

{
"type":"div",
"props":{"children":[a]}
}

{
"type":"div",
"props":{"children":[a, b]}
}

Thechildren array could also contain primitive values like strings or numbers. So we’ll wrap everything that isn’t an object inside its own element and create a special type for them:TEXT_ELEMENT.

React doesn’t wrap primitive values or create empty arrays when there aren’tchildren, but we do it because it will simplify our code, and for our library we prefer simple code than performant code.

We are still using React’screateElement.

In order to replace it, let’s give a name to our library. We need a name that sounds like React but also hints itsdidactic purpose.

We’ll call it Didact.

But we still want to use JSX here. How do we tell babel to use Didact’screateElement instead of React’s?

If we have a comment like this one, when babel transpiles the JSX it will use the function we define.

Step II: Therender Function

Next, we need to write our version of theReactDOM.render function.

For now, we only care about adding stuff to the DOM. We’ll handle updating and deleting later.

We start by creating the DOM node using the element type, and then append the new node to the container.

We recursively do the same for each child.

We also need to handle text elements, if the element type isTEXT_ELEMENT we create a text node instead of a regular node.

The last thing we need to do here is assign the element props to the node.

And that’s it. We now have a library that can render JSX to the DOM.

Give it a try oncodesandbox.

There’s a problem with this recursive call.

Once we start rendering, we won’t stop until we have rendered the complete element tree.If the element tree is big, it may block the main thread for too long. And if the browser needs to do high priority stuff like handling user input or keeping an animation smooth, it will have to wait until the render finishes.

So we are going to break the work into small units, and after we finish each unit we’ll let the browser interrupt the rendering if there’s anything else that needs to be done.

We userequestIdleCallback to make a loop. You can think ofrequestIdleCallback as asetTimeout, but instead of us telling it when to run, the browser will run the callback when the main thread is idle.

Reactdoesn’t userequestIdleCallback anymore. Now it uses thescheduler package. But for this use case it’s conceptually the same.

requestIdleCallback also gives us a deadline parameter. We can use it to check how much time we have until the browser needs to take control again.

while(nextUnitOfWork){
  nextUnitOfWork=performUnitOfWork(
    nextUnitOfWork
)
}

To start using the loop we’ll need to set the first unit of work, and then write aperformUnitOfWork function that not only performs the work but also returns the next unit of work.

Suppose we want to render an element tree like this one:

Didact.render(
<div>
<h1>
<p/>
<a/>
</h1>
<h2/>
</div>,
  container
)

In therender we’ll create the root fiber and set it as thenextUnitOfWork. The rest of the work will happen on theperformUnitOfWork function, there we will do three things for each fiber:

1. add the element to the DOM
2. create the fibers for the element’s children
3. select the next unit of work

One of the goals of this data structure is to make it easy to find the next unit of work. That’s why each fiber has a link to its first child, its next sibling and its parent.

When we finish performing work on a fiber, if it has achild that fiber will be the next unit of work.

From our example, when we finish working on thediv fiber the next unit of work will be theh1 fiber.

If the fiber doesn’t have achild, we use thesibling as the next unit of work.

For example, thep fiber doesn’t have achild so we move to thea fiber after finishing it.

And if the fiber doesn’t have achild nor asibling we go to the “uncle”: thesibling of theparent. Likea andh2 fibers from the example.

Also, if theparent doesn’t have asibling, we keep going up through theparents until we find one with asibling or until we reach the root. If we have reached the root, it means we have finished performing all the work for thisrender.

First, let’s remove this code from therender function.

We keep the part that creates a DOM node in its own function, we are going to use it later.

In therender function we setnextUnitOfWork to the root of the fiber tree.

Then, when the browser is ready,it will call ourworkLoop and we’ll start working on the root.

First, we create a new node and append it to the DOM.

We keep track of the DOM node in thefiber.dom property.

Then for each child we create a new fiber.

And we add it to the fiber tree setting it either as a child or as a sibling, depending on whether it’s the first child or not.

Finally we search for the next unit of work.We first try with the child, then with the sibling, then with the uncle, and so on.

And that’s ourperformUnitOfWork.

Step V: Render and Commit Phases

We have another problem here.

We are adding a new node to the DOM each time we work on an element.And, remember, the browser could interrupt our work before we finish rendering the whole tree.In that case, the user will see an incomplete UI. And we don’t want that.

So we need to remove the part that mutates the DOM from here.

Instead, we’ll keep track of the root of the fiber tree. We call it the work in progress root orwipRoot.

And once we finish all the work (we know it because there isn’t a next unit of work) we commit the whole fiber tree to the DOM.

We do it in thecommitRoot function. Here we recursively append all the nodes to the dom.

Step VI: Reconciliation

So far we onlyadded stuff to the DOM, but what about updating or deleting nodes?

That’s what we are going to do now, we need to compare the elements we receive on therender function to the last fiber tree we committed to the DOM.

So we need to save a reference to that “last fiber tree we committed to the DOM” after we finish the commit. We call itcurrentRoot.

We also add thealternate property to every fiber. This property is a link to the old fiber, the fiber that we committed to the DOM in the previous commit phase.

Now let’s extract the code fromperformUnitOfWork that creates the new fibers…

…to a newreconcileChildren function.

Here we will reconcile the old fibers with the new elements.

We iterate at the same time over the children of the old fiber (wipFiber.alternate) and the array of elements we want to reconcile.

If we ignore all the boilerplate needed to iterate over an array and a linked list at the same time, we are left with what matters most inside this while:oldFiber andelement.Theelement is the thing we want to render to the DOM and theoldFiber is what we rendered the last time.

We need to compare them to see if there’s any change we need to apply to the DOM.

To compare them we use the type:

• if the old fiber and the new element have the same type, we can keep the DOM node and just update it with the new props

• if the type is different and there is a new element, it means we need to create a new DOM node

• and if the types are different and there is an old fiber, we need to remove the old node

Here React also uses keys, that makes a better reconciliation. For example, it detects when children change places in the element array.

When the old fiber and the element have the same type, we create a new fiber keeping the DOM node from the old fiber and the props from the element.

We also add a new property to the fiber: theeffectTag. We’ll use this property later, during the commit phase.

Then for the case where the element needs a new DOM node we tag the new fiber with thePLACEMENT effect tag.

And for the case where we need to delete the node, we don’t have a new fiber so we add the effect tag to the old fiber.

But when we commit the fiber tree to the DOM we do it from the work in progress root, which doesn’t have the old fibers.

So we need an array to keep track of the nodes we want to remove.

And then, when we are commiting the changes to the DOM, we also use the fibers from that array.

Now, let’s change thecommitWork function to handle the neweffectTags.

If the fiber has aPLACEMENT effect tag we do the same as before, append the DOM node to the node from the parent fiber.

If it’s aDELETION, we do the opposite, remove the child.

And if it’s anUPDATE, we need to update the existing DOM node with the props that changed.

We’ll do it in thisupdateDom function.

We compare the props from the old fiber to the props of the new fiber, remove the props that are gone, and set the props that are new or changed.

One special kind of prop that we need to update are event listeners, so if the prop name starts with the “on” prefix we’ll handle them differently.

If the event handler changed we remove it from the node.

And then we add the new handler.

Step VII: Function Components

The next thing we need to add is support for function components.

First let’s change the example. We’ll use this simple function component, that returns anh1 element.

Note that if we transform the jsx to js, it will be:

functionApp(props){
returnDidact.createElement(
"h1",
null,
"Hi ",
    props.name
)
}
const element=Didact.createElement(App,{
name:"foo",
})

Function components are differents in two ways:

• the fiber from a function component doesn’t have a DOM node
• and the children come from running the function instead of getting them directly from theprops

We check if the fiber type is a function, and depending on that we go to a different update function.

InupdateHostComponent we do the same as before.

And inupdateFunctionComponent we run the function to get the children.

For our example, here thefiber.type is theApp function and when we run it, it returns theh1 element.

Then, once we have the children, the reconciliation works in the same way, we don’t need to change anything there.

What we need to change is thecommitWork function.

Now that we have fibers without DOM nodes we need to change two things.

First, to find the parent of a DOM node we’ll need to go up the fiber tree until we find a fiber with a DOM node.

And when removing a node we also need to keep going until we find a child with a DOM node.

Step VIII: Hooks

Last step. Now that we have function components let’s also add state.

Let’s change our example to the classic counter component. Each time we click it, it increments the state by one.

Note that we are usingDidact.useState to get and update the counter value.

Here is where we call theCounter function from the example. And inside that function we calluseState.

We need to initialize some global variables before calling the function component so we can use them inside of theuseState function.

First we set the work in progress fiber.

We also add ahooks array to the fiber to support callinguseState several times in the same component. And we keep track of the current hook index.

When the function component callsuseState, we check if we have an old hook. We check in thealternate of the fiber using the hook index.

If we have an old hook, we copy the state from the old hook to the new hook,if we don’t we initialize the state.

Then we add the new hook to the fiber, increment the hook index by one, and return the state.

useState should also return a function to update the state, so we define asetState function that receives an action (for theCounter example this action is the function that increments the state by one).

We push that action to a queue we added to the hook.

And then we do something similar to what we did in therender function, set a new work in progress root as the next unit of work so the work loop can start a new render phase.

But we haven’t run the action yet.

We do it the next time we are rendering the component, we get all the actions from the old hook queue, and then apply them one by one to the new hook state, so when we return the state it’s updated.

And that’s all. We’ve built our own version of React.

You can play with it oncodesandbox orgithub.