Of course our version of React elides over many details that React must contend with, like starting a re-render from where state changes and event handlers. For understanding how to build high-performance React applications, however, the most important piece to understand is how and when React renders components, which is what we have learned in creating our own mini version of React.
At this point you should have an understanding of how React works. In the rest of the book we are going to be refining this model and looking at practical applications of it so that we are prepared to build high performance React applications and diagnose any bottlenecks.
At this point, you should now have an understanding of how React works. You should now understand why using a good `key` is so critical, what it actually means to have React render a tree of components, and how React chooses when to replace a node or re-use one. If your React application is performing poorly you can think about which part of the algorithm or heuristics might be the issue.
Now, there is a lot more to explore. Like how do you track down the cause of a performance bottleneck? Or how do you use the React APIs in a performant way? These types of questions should be easier to track down and understand with the foundations covered and I hope this is only the start of your High-Performance React journey.
The actual React implementation used to look very similar to what we've built so far, but with React 16 this has changed dramatically with the introduction of Fibers. Fibers are a name that React gives to discrete units of work during the render process. And the React reconciliation algorithm was changed to be based on small units of work instead of one large, potentially long-running call to `render`. This means that React is now able to process just part of the render phase, pause to let the browser take care of other things, and resume again. This is the underlying change the enables the experimental Concurrent Mode as well as running most hooks without blocking the render.
But even with such a large change, the underlying algorithms for deciding how and when to render components is the same. And when not running in Concurrent Mode the effect is still the same as React does the render phase in one block still. So using a simplified interpretation that doesn't include all the complexities of breaking up the process in to chunks enables us to see more clearly how the process as a whole works. At this point bottlenecks are much more likely to occur from the underlying algorithms and not from the Fiber specific details. In the chapter on Concurrent Mode we will learn more about Fibers.
But even with such a large change, the underlying algorithms for deciding how and when to render components is the same. And when not running in Concurrent Mode the effect is still the same as React does the render phase in one block still. So using a simplified interpretation that doesn't include all the complexities of breaking up the process in to chunks enables us to see more clearly how the process as a whole works. At this point bottlenecks are much more likely to occur from the underlying algorithms and not from the Fiber specific details.
Welcome to *Foundations of High-Performance React* where we build our own simplified version of React. We will use our React to gain an understanding of the real React and how to build high-performance applications with it.
Welcome to *Foundations of High-Performance React Applications* where we build our own simplified version of React. We will use our React to gain an understanding of the real React and how to build high-performance applications with it.
This book is based on the first chapter of the book *High-Performance React*. If you enjoy *Foundations of High-Performance React Applications* and you want to learn more practical ways to utilize the foundations we will learn here and get a more detailed blue-print for creating high performance React applications, then be sure to check out *High-Performance React*.
*Foundations of High-Performance React Applications* is not intended to be an introduction to React or JavaScript. While it might be useful to beginners, this book assumes familiarity with both JavaScript and React.
For the code in this book, the goal is to be clear and simple; to best communicate the algorithms we will be exploring. It is not intended to be used in production but it is functional and you will likely find it useful to follow along by also writing the code yourself. It will help you better understand how it works, and even more critically, it will allow you to play with it and test how the algorithms work with your own examples.
Even if you don't write out the code yourself and instead treat this book more as a novel you read through and then move on, I believe the fundamentals should still stick with you and provide value in your React programs-to-come.
I'm very excited to take you on this journey with me and now it's time to learn what lays at the very foundation of React.
Throughout the rest of the book we will be building on and using our React implementation so it would be helpful to see it all put together and working. At this point the only thing left to do is to create some components and use them!
At this point the only thing left to do is to create some components and use them!
@ -13,7 +13,9 @@ According to the [React documentation](https://reactjs.org/docs/reconciliation.h
* Elements of differing types will yield different trees
* You can hint at tree changes with the `key` prop.
In this section we will focus on the first part: differing types. In a later chapter we will discuss and implement the `key` prop.
In this section we will focus on the first part: differing types.
> In this book we won't be covering keys in depth but you will see why it's very important to follow the guidance from React's documentation that keys be: stable, predictable, and unique.
The approach we will take here is to integrate the heuristics that React uses into our `render` method. Our implementation will be very similar to how React itself does it and we will discuss React's actual implementation later when we talk about Fibers.
It's very important to understand the algorithm used here because this is essentially what happens in React when incorrect keys are used, like using a list index for a key. And this is why keys are so critical to high performance (and correct) React code. For example, in our algorithm here, if you removed an item from the front of the list you may cause every element in the list to be created anew in the DOM if the types no longer match up. Later on, in the chapter on keys, we will update this algorithm to incorporate keys. It's actually only a minor difference in determining which `child` gets paired with which `prevChild`. Otherwise this is effectively the same algorithm React uses when rendering lists of children.
It's very important to understand the algorithm used here because this is essentially what happens in React when incorrect keys are used, like using a list index for a key. And this is why keys are so critical to high performance (and correct) React code. For example, in our algorithm here, if you removed an item from the front of the list you may cause every element in the list to be created anew in the DOM if the types no longer match up. In this book we won't be incorporating keys, but it's actually only a minor difference in determining which `child` gets paired with which `prevChild`. Otherwise this is effectively the same algorithm React uses when rendering lists of children.
{caption: "Example of `renderChildren` 2nd loop when the 1st element has been removed. In this case the trees for all of the children will be torn down and rebuilt."}
