@ -208,8 +208,6 @@ According to the React documentation their diffing algorithm is O(n) and based o
In this section we will focus on the first part: differing types. Later on we will discuss and implement the `key` prop.
TODO some kind of call-out for big deal
TODO <https://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf>
The approach we will take here is to integrate the heuristics that React uses into our render method. This is similar to how React itself does it and we will discuss React's actual implementation later when we talk about Fibers.
@ -309,6 +307,8 @@ function createDOMElement(element) {
To set the props on an element we first clear all the existing props and then loop through the current props, setting them accordingly. Of course we filter out the `children` prop since we use that elsewhere and it isn't intended to be set directly.
#+NAME Setting DOM Props
{format: "javascript"}
```
function setDOMProps(element, domElement, prevElement) {
@ -327,9 +327,9 @@ function setDOMProps(element, domElement, prevElement) {
}
```
TODO note that React is more intelligent settings props, it only updates the ones that need to update
> React is more intelligent about only updating or removing props that need to be.
TODO this algorithm doesn't correctly handle event handler props but we're ignoring that for simplicity
W> This algorithm for setting props does not correctly handle events which must be treated specially. For this exercise that detail is not important though.
For rendering children we use two loops. The first loop removes any elements that are no longer being used. This would happen when the number of children is decreased. The second loop starts at the first child and then iterates through all of the current children calling `render_internal` on each child. When `render_internal` is called the corresponding previous element in that position is passed to `render_internal` or `undefined` if there is no corresponding element, like when the list of children has grown.
@ -360,6 +360,10 @@ The actual React implementation used to look very similar to what we've gone thr
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 go in to this more.
## Conclusion
At this point you should have enough information to begin to diagnose performance issues and prevent them from occurring in the first place. 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.
