This lesson explains how you can build larger trees of react component and how they are managed efficiently by MobX. You will learn how to pass observable data structures around in props and how the Devtools can be used to analyze the performance of your UI.
Here we have our list of temperatures again. We have initialized this with the three temperatures and we have our app that loops of these temperatures and renders them. Here they are.
This view is a bit silly. Let's fix this. What we want to do is when we click this temperature that it increases the temperature. At the convenience you already introduced the increment action which just adds one degree to the temperature. What we can do now is simply add an onclick handler, and we say that it needs to increment the temperature. Now, if you click it, the temperature increases.
That works but it isn't very efficient, because as you can see, every time we click one of the temperatures, all of them re-renders. That is because there's only one component which renders all of the temperatures, so it has to react to all of the temperatures. Let's fix that. Let's use a divide and conquer strategy and split up those components.
So far we have this status finish components which takes properties and produces their rendering. We simply declare a new class and this time, we use the ES6 class of style to demonstrate how that works. We call this class T-view, which isn't the best name, but the temperature is already in use in this single file. In a real app, you would, of course, split this up into separate files.
We move the list elements to the new render function. We grab the temperature from the properties and we invoke this new component from our original app components. We still need to pass in a key for that we'll be able to reconcile these components, but we no longer need the key and the new components. Let's remove that.
Then we run this and now click the list items. Nothing happens and that is because our new component isn't reactive. We can simply fix that by adding the observer decorator. Now we render again, and we once again use the desk view to see when the components render, and we see now that they individually re-render when we click them.
Also, if we push new temperatures onto the list, you see that MOBEX has now optimized the rendering of our components. The parent component is re-rendered because an item is added and the new child is rendered, but the other childs aren't.
When MOBEX starts behind the scenes it's implementing shoot component updates so that parent components can render independently of their childs and childs independently of their parents. If we change another one we see that MOBEX now exactly has determined which components need to be updated for each change.
Now we have split up our small components, but this onclick handler here inline is still a bit ugly. Let's refactor that nicely to an action. We now nicely have split off our event handler into a separate action which is invoked from rendering and still works as expected.
Now we have two real components. One, status finish component which maps over our temperatures, and we have the temperature view components, which has a simple action and renders independently of its parents.