‫Let's now learn about a simple performance
‫optimization technique which leverages the children prop
‫in order to prevent some components from re-rendering.
‫Now, this isn't the most used technique out there,
‫but it gives us actually surprising insights
‫into how React works internally.
‫And so that's why I wanted to share this with you.
‫Also, not many people know about
‫that this is how React works,
‫and so this makes this even more interesting.
‫Now, in this lecture, I want to bring in
‫this test component inside the test.js file
‫which was part of this project here in the beginning.
‫So this test component implements a very simple Counter,
‫so it has a button to increase the count
‫and it also displays that count,
‫and then the count also contains the SlowComponent.
‫And so what the SlowComponent does is to
‫basically create 100,000 words and place them into an array
‫and it then renders this 100,000 element long array
‫here in our user interface.
‫And so let's now include that here below our list
‫just to see what's gonna happen.
‫So this is basically an experiment with which
‫I will show you that optimization technique
‫that I was talking about.
‫So let's include that.
‫And it's not list, of course it is test.
‫So let's include the test here inside the list,
‫and then let's see what we get here.
‫And by the way, if your application
‫is taking way too long to load,
‫you can always quit the application and restart it
‫or you can try to reduce the number of elements right here.
‫So maybe 100,000 is a bit too much for your case,
‫and yeah, so if that doesn't work for you,
‫then just change the number of words there.
‫So you see we have like this infinite amount of words now,
‫and the idea here is that this simulates
‫a very SlowComponent.
‫And so let's see what happens as we click here.
‫So I click and then it takes like half a second
‫until the button actually updates.
‫So let me do that again.
‫So maybe you can hear my click.
‫Let me do that just one more time.
‫And probably for you, it also takes this long.
‫And so the reason for that is right here.
‫So basically here, each time we click on the button,
‫this state updates,
‫and so this entire component needs to get re-rendered.
‫And so therefore this SlowComponent is also re-rendered
‫each time that we click the button
‫even though this actually isn't really
‫dependent on the state.
‫So the SlowComponent does not need the state at all
‫but still it is being re-ordered
‫simply because it is inside this test component.
‫So, if you ever find yourself in a situation like this
‫where you have one kind of SlowComponent inside another one
‫which updates this one without it needing it,
‫this is where you can then use this optimization technique.
‫So what I'm gonna do is to take the
‫Counter functionality out,
‫so Counter like this,
‫and let me just copy all of it,
‫but here, not the SlowComponent,
‫but instead here I will now render the children prop
‫because we will now pass this SlowComponent
‫into the Counter as children.
‫So let me command all of this here out
‫and let's return a new diff
‫here with the same h1, just so it all looks the same.
‫And then here comes the Counter.
‫So just like this.
‫And then this is where we place the SlowComponent.
‫And so this actually looks exactly the same.
‫So the componentry will also be exactly the same
‫where we see here that basically we still have the h1,
‫the button and then in the UI, the SlowComponent.
‫So this entire list here.
‫However, it will now work in a completely different way.
‫So let's see what happens now when I click here
‫and you see that it is instant, right?
‫So this means that actually probably this list here
‫is no longer being re-rendered,
‫and we can actually prove that by clicking here now
‫on the Start profiling button,
‫then updating the state by clicking on the button
‫and then stopping it here.
‫So here is of course the Counter.
‫So the Counter component needed to update,
‫but then we see that the SlowComponent did not render.
‫So why is that?
‫Even though basically our JSX is very similar,
‫so the structure of the output is very similar,
‫and indeed it does look exactly the same
‫as it looked like here in the UI previously, right?
‫So the only thing that we changed is
‫that we no longer have SlowComponent here like this,
‫but instead we pass it in as a children.
‫So then here we display it as a children.
‫So why does this work this way?
‫So why is suddenly React no longer
‫re-rendering this component?
‫Well, again, this element, the SlowComponent,
‫has this time been passed in as a children prop.
‫And so what this means is that this component here
‫was actually already created
‫before the Counter component re-rendered.
‫And so therefore, there's no way in which this component
‫could have been affected by the state change
‫in the Counter, right?
‫So again, as React sees this piece of JSX here,
‫it will basically immediately create
‫the SlowComponent right here
‫and then pass it into the Counter.
‫So all while rendering.
‫And then as we click here on this button,
‫the Counter is of course re-rendered,
‫but this component again has already been
‫pressed in as a prop,
‫So it has already been created before
‫and so it cannot be affected by that state update.
‫It already exists.
‫And so that is the reason why React then bails out of
‫re-rendering this children component
‫because nothing could have changed
‫inside of the SlowComponent.
‫So React is smart enough like this
‫and can therefore decide not to re-render this.
‫Okay?
‫So hopefully this made sense
‫and that you found it as interesting as I did.
‫So when I first found out about this not too long ago,
‫I was quite surprised that React works this way.
‫And so you might actually find situations like this
‫in the real world in your own code.
‫And so in that case, just be aware that this trick exists.
‫So all you have to do is to refactor your code a little bit
‫so that you can pass the SlowComponent,
‫whatever it is named in your case, as a prop.
‫And it could also be some other prop.
‫So you can call this like, show this, or whatever
‫and then you pass the SlowComponent in there like this.
‫So that would work exactly the same
‫because then also React would already have been
‫created this component here
‫before anything ever happens inside the Counter.
‫All right?
‫And this is really all I wanted to do
‫with this test component.
‫So let's now get our application back to normal.
‫But this actually has another very interesting application
‫in the way that our context works right now.
‫So let me again start profiling here
‫and just search once and then stop this.
‫And so here we see again that these two components
‫have not been re-rendered, but why is that?
‫Why have they not been re-rendered?
‫I mean, there has been a state update
‫inside the PostProvider component, right?
‫So this PostProvider right here is actually
‫just a regular component.
‫And so when we searched here,
‫we updated this state which then re-rendered this component.
‫And so therefore all the child components
‫should have re-rendered as well, right?
‫So all of these should have re-rendered as well
‫if we follow that logic,
‫because, again, all of them are child components.
‫However, we see, again, that these two did not re-render.
‫And the reason for that is exactly the same
‫that we saw earlier with the test and the SlowComponent.
‫So the reason again is that all of these
‫child components here were actually
‫passed into the PostProvider as children.
‫And so we are in the exact same situation as before
‫where all these child components were already created
‫before they were passed here into this component.
‫And so then React once again bails out of re-rendering
‫all of them because they couldn't have possibly
‫been affected by any state change,
‫unless, of course, they do actually consume
‫the context itself.
‫So that's the case for this one.
‫Well, now we cannot see that
‫because I reloaded the page in the meantime,
‫so I would need to turn this setting back on,
‫but this only works for the next time.
‫Well, let's just do that now again.
‫All right.
‫So yeah, now we can see that, make this a bit bigger.
‫And so this one here did re-render again
‫because the state has updated,
‫and then this one has changed only
‫because the context has changed,
‫not because the parent component has re-rendered.
‫So the same here, and the same here.
‫While again, these ones were not re-rendered
‫because they were passed in as children
‫and so they were already created
‫before the PostProvider was even created.
‫And so they could not have been affected
‫by any state change in there.
‫Okay, so I hope that made sense
‫and that you keep this technique in the back of your mind
‫even though it is probably not used all the time.
‫But it's very, very interesting,
‫and I think this like puts you in the top 1% of
‫React developers when it comes to
‫knowing about this kind of stuff.