React Performance Optimization Patterns Course

What is discussed, and when

1. 40:00 – 50:00: GitHub, Tapascript
2. 50:00 – 1:00:00: React 19
3. 1:20:00 – 1:30:00: GitHub, react window
4. 1:30:00 – 1:35:58: Tapascript, React 19, react window

Notable quotes from "React Performance Optimization Patterns Course"

• See day 11 and all this code that I've showed over here will be there. Also join Tapascript Discord where you can talk to other developers and we also can talk sometime and…

  about Tapascript · at 48:22

• Learning out of this you are spending some time right out of your life let it be of a great use. React 19 introduced something called React compiler which automatically…

  about React 19 · at 50:47

• Information of the user. But for the virtual list I'm using a library called react window that helps us in getting virtualization in react. From that I use the component called…

  about react window · at 1:23:21

Who and what is mentioned in this episode?

Companies & orgs

• Tapascript — Company · 3 mentions · first at 48:26
• GitHub — Company · 2 mentions · first at 48:10
• Babel — Company · 2 mentions

Products & tech

• react window — Product · 2 mentions · first at 1:23:25

Concepts & topics

• React — Concept · 15 mentions
• React 19 — Concept · 8 mentions · first at 50:51

Full transcript with timestamps

0:00 React makes it easy to build UIs, but building fast React apps is a different skill altogether. In this hands-on real world React performance optimization crash course, you'll learn how React actually rerenders, why your app slows down, and which performance patterns truly matter in production. Not just theory, but battle tested techniques used by senior engineers. This video is about knowing what to optimize, when to optimize, and how to do it right. top has created this course.

0:31 Hey, hello everyone. How are you doing? Welcome back to performance patterns. Yes, it's plural patterns because we are going to talk about multiple patterns that can help you to optimize performance of your ReactJS app. What I have seen in my career coding with ReactJS extensively that most of the performance concerns come from only one thing that is rerendering. when your react apps render when state changes when props value changes when context value changes if the parent component rerenders isn't it so in all these cases the rerendering may happen so if we can control rerendering I think we'll be able to address most of the performance issues after understanding a part of rerendering in react we are going to talk about the techniques that we're going to learn in this session is called memorization derive state debounce and throttle ling. We're also going to look into splitting components,

1:26 virtualization, context optimization, React compiler. These all are different techniques through which you can control performance degradation of your application and each of these pointers will bring design patterns that you can adhere to to make sure that the performance of your application is taken care. As you can see, there are a lot of things to be done. I thought of splitting this session into two part one and part two. As part of part one, we are going to cover from moiation to debounce and throttling and rest of the pieces will be taken into the part two.

2:01 So before we start talking about any techniques, it makes lot of sense to look into rerendering and take some examples. Here on your screen you are seeing an application. This application is a combination of a parent component and a child component. This particular text box what you see over here is part of the parent component and on top of that you're seeing something called rendered colon two times that is a child component. Now any changes that I make in the parent component in state changes of course the parent component will rerender that's how react works. We have spoken about it already when the state changes props changes context value changes or the parent component changes the rerendering happen. So it's out of React's own philosophy. If I change the state of the parent component, the child component also rerenders. This is how it happens. If I put a letter over here, a character over here like A, I am seeing

2:55 this two jump to four. If I type one more V, it becomes six. If I keep typing, it keep increasing. So it means for every change of the state of the parent component, the child component is randing. Now you might be asking question that okay fine it is rerendering but why the value is going double? Why it is not single? It is because react runs something called a strict mode. That's why the rerendering happens twice. Okay this has happened only on de mode if the strict mode is on. If the same code is running on the production mode this is not going to happen. Now this is the parent component which is called render tracker demo. So what is this component doing? As I told it has an input box. This is the input box and it has a state called value.

3:38 What is happening? Whenever there is a change happening in the input box, I'm typing certain character. I am just changing this value using the set value updator function that I get from the use state. We all know that that means I'm changing the state of this particular component. Now this component also has a child component which is called render tracker. We'll go there in a moment. Now whenever a state value changes of this parent component, React forces the child component to rerender. That is why we were seeing the rendering count. You don't see the rendering count anywhere in the parent component because the rendering count is kept in the child component. Let's go to the child component. Now over here you are seeing this rendering count. It is happening renderscurren what I am showing this simple react component act as an child component over here which keeps tracks of how many time it gets rendered. Now

4:31 if you have seen the previous session I clearly called out the difference between use state and user ref. Use state with every render the value will be flushed out cleared reinitialized but for use ref in every render the value will be retained and also changes of the use ref value doesn't force for a render whereas the changes of the state value force for a render right we have learned all these different nitty-g now here I have used the use rate because I wanted to preserve the value of rendering across multiple renders and this is the same exact value what I'm increasing I am displaying also. So it means that if my parent component rerenders due to this state change value over here it is forcing the child component also to rerender and I'm able to see this over here. That's exactly we are seeing over here. So this is just to show you just to set the ground that what rerendering means and sometimes rerendering this

5:31 child component because parent component is rrendering might cause a lot of trouble. So all the techniques that we'll be talking about today in the part one are going to take care this kind of rerendering which may not be required how can we stop them in a optimal way. The first technique is memorization. What does it mean memorization is basically a computer programming optimization technique. techique I would say which to speed up your program by storing the result of a function's execution and then use the stored result the cacheed result if the input to the function doesn't change. So if we take a function say f(x) where x is the input and it produces a result say y and now we can cache this particular result and anytime someone call this function we will always return this same result as long as the input provided to the function remains same. This particular technique is called memorization

6:33 technique. So it's a caching technique where you can cache the output value of a function and always return the same value as long as the input to the function remains same. If the input to the function changes for example from X if it become P of course it may not going to return Y again right it's probably going to return Z in that case memorization technique won't be returning the old Y value rather it is going to catch the Z value and going to return the Z value again this is how the memorization technique works now in React there are three different ways we can do memorization technique first using a function called memo that's provided by React Second, React provide a hook called use call back. Using that we can apply memorization technique on our React components. And the last one is called a hook called use memo. Using that also we can achieve the memorization on our React component and

7:28 the React application. However, each of these techniques has got their own benefit and the disadvantages. We are going to talk about each of these technique going to show some examples. However, in the modern React, there is something called React Compiler which we're going to cover in the part two. And I've already created a video on React Compiler extensively when it got released initially. But I'm going to talk about React compiler in the context of the latest version of React in the part two where we'll be talking about how some of this memorization technique like memo, use call back, use memo you should be looking at if you are building a React application from the scratch today versus a React application that is already there as a legacy code with you.

8:08 But that's part two. Now in part one, let's take a look into each of these technique one by one. First memo, then use call back and then the use memo. Take a look into this application almost similar to the one that we have seen before that whenever this application got rendered first time it locked something called rendered profile card. It means that I have a component called profile card and it render profile card. Now let me tell you profile card is a child component over here which is showing the profile information. Now in the parent component like before I have a text box over here and look at what happens when I type a key over here. I'm typing a. The moment I type a the profile card got the log for rendering profile card came here. However, this rendered profile card is there only in the child component. It is not there in the parent component. So it means like before as you have seen once the parent

8:58 component is rerendering it is forcing the child component also to rerender. Now I keep typing character. If you see in my right side console is going to keep logging. It's again logging twice. I have given this explanation before and in fact you can see in the debugging tool the one coming because of the strict mode is in much more muted color. Now let us take a look into the code. This is a parent component. Again like before I have a input box. I have a state called value and I am changing the value of it on every key type. And there is a child component called profile card. Whatsoever this profile card is never ever related to this value. I am not passing this value as a props at all. I am passing a hard-coded name called tapus. That means this profile card is not changing because it has a dynamic prop value. It is changing because its parents state value I am changing here using the onchange. You

9:52 see over here that's the reason by react philosophy the child component is reding. Now if I go inside this child component, it's a very simple component. takes the prop and it just says that render the profile card and showing that particular hardcoded prop. Now if I think that I have a child component and that child component I should not render at any cost until unless the input to the component changes I can use the technique of memorization and the first technique as I told is using the higher order function that react provides called memo. So the first thing that we'll be doing is to import the higher order function called memo from react.

10:30 So I've imported memo from React and then you have to encapsulate this entire React component function inside this memo function. You know what higher order function is. If you have followed my 40 days of JavaScript, I have clarified all these concepts very clearly. A function that takes another function as an argument or can return a function from itself is called a higher order function. So memo is a high order function because now you can do something like this. You can use this memo and then you can pass this entire component function that we had to get a completely new memoized function. Now this memoized function is your memorized component. So instead of exporting the profile card which you are doing before, let us just export the memoise card.

11:15 Simple enough. So this is what you need to do. That much alone is enough. So you have imported the memo higher order function. As it is a higher order function, it can take another function as an argument. You have passed your component function got a memorized function and you exporting from here. Coming to your parent component there is no changes required. If you just want you can probably this name as a memoized card because you are doing an export default. You can import with any name. It makes sense to do it as memoized card because you can then recognize it's something that you have memorized intentionally. Now the behavior will change here. First time when it got rendered render profile card. Great. Now I'm going to press one character. that's going to change the state value of my parent component. But this is never ever going to change anything for my child component because child component is

12:02 taking a hard-coded props. Right? So first value if I'm pressing nothing happens. My child component is not rerendering because I am not getting reader profile card again. I'll type more characters. I'm keep typing characters. You see here my child component is not rendering. It is because the memorization is done over here and the child component is taking a hard-coded value over here like so until and unless this value gets changed this props gets changed the child component is never ever going to rerender even when the parents component state value is changing over here. So this is the first step. Now let us understand the next tool that we have is called use call back for this memorization pattern.

12:45 Now I didn't show you the application rather let us start with the code because just now we have learned about this memo isn't it the memoization. So see this code should be familiar to you. I have a component called child and this child component is a very simple component which takes a props and then console.log says the child rendered and return a simple button. The button has a on click and click on it what function to call that is what get passed as a prop. So this is a very very simple react component but the twist over here is that this particular react component is passed to the higher order function called memo so that we get a memoized version of it and this is what we have exported from here. Cool very simple memoized thing. Now let's go to the parent component. We have imported the child just like before parent component has it own state called count. It got its own button called increment. The

13:38 moment I click on this button, the value of the count goes up by one using the set count updator function. So on click, I am calling this set count + one. It means this count value will be increased by one. It means I'm changing the state of my parent component. I have also used the child component over here. And as I have explained, the child component takes a onclick props which is over here. I pass the function that should be executed when somebody click on a button which is inside the child component. Now what do you think is going to happen if the parents component state count gets changed? So far we have learned that using memoization if the child component can be passed through the memo higher order function until unless the input gets changed my child component is never going to rendered even if the parents component state gets changed. parent components render because of any reason.

14:35 So in this case, ARNU is satisfying two cases. One, the child component is already memorized and the props of the child component, the props value of the child component is quite static. It is never going to change. So it means that if the parent component state changes because of this button click, the child component should never get rerender. I should not see this console.log lock child render when I am clicking on this increment button. This is what my expectation. Now let's go and look into the application. So first time of course app render child rendered. That's great because first time it has to render. Now I'm going to click on this increment.

15:13 Look at here what happens. I click on increment. Oh my god it again printed app render child render and I click over here app render child render. Oh my god. So that means when parents component state is getting changed, child component is also getting rerendered even when I have used the memoization technique. Why is it so? So here basic JavaScript come into picture guys. No react nothing. React memo is fantastic. It rerender your component only when the prop changes. However, when comes inline functions like this though it looks like it's a static function I am passing to on click. Now the beautiful part of function is just like an object in JavaScript it's of reference type. So on every render a new reference of this function will be created. So if a new reference of this function gets created on every render it means the onclick value on every render of this component is new. Isn't it? First time when my

16:16 parent component got rendered this particular function's reference value was let's say x. Now when I click on this button to change the count value that is the state of my parent component my parent component will get rerender. The moment the parent component get rerender this particular line this particular value will get a completely new function which is having a new reference in the memory. Though it may look exactly same with the previous version of it as it's a new reference completely new function it means the prop value had got changed. So of course the child is going to get rerendered even when the memoation has been applied. So this is what you need to really observe closely. Inline arrow functions break memorization because they create new identity every render.

17:06 This is the thumb rule. This is the mental model that you need to keep it. Now to fix this React gives us something called use call back. That's a inbuilt hook that react gives us which helps by stabilizing the function references. So it means that when I use use call back hook use call back hook is never ever going to look into only the shape of this particular function rather it is going to look into the reference of it. So, so far whatever happened is like inline function every render new reference created. New reference got created means browse value changed my memo breaks and my child component got rerendered. But with use callback it will ensure that react dome will see always the same object. Can you change the code? Yes. Now to change the code it's pretty simple. Let us take this one the onclick one into a function called handle click.

18:00 And over here let us import use call back and define con handleclick equals to use call back which takes a call back function inside which you have to write what you want to do. Let's say I write console dot log of say clicked and then you have to pass something called an dependency array. So this dependency array is similar to what we have seen in use effect earlier right if you don't pass anything it is just once but if you can pass any dependencies whenever the dependency changes only then you explicitly tell that even if the memorization applied on the child I want to rerender the child but until unless my dependencies are not changing their value is not changing use callback would ensure that even if you have a memorization over here will ensure that your child component doesn't get rerendered right so that's the difference so with this can we run this app first time app render parent

19:01 rendered child render now let me click on increment only app rendered I don't see child rendered anymore only app rendered only parent render rendered now if I click on a button that is there in the child I'll only see the child rendered so click child clicked child clicked only child rendered if I click on the parent one only parent rendered you see this now My memorization technique is working really well. So what are the things happened over here? When I click on increment, my parent component renders but the handleclick function over here doesn't get recreated because handle click is now very much memorized using use call back. Child receives the same function. This handleclick function always on every rerendering of the parent. As the handle click is not been recreated, it always pass the same reference. That means the value of on click remain intact just like before and then child doesn't get

19:55 rerendered. Now imagine if there is a dependency value that I'm passing to use call back and if the dependency value changes only then this handle click will have a new reference and that reference value goes over here that means the props value of child changes now child gets red. This is exactly guys use callback does. Now many people just use the syntax but they may not understand the depth of it like how it works. I tried my best to give that to you. I hope it makes sense to you and I want to know like how is this 15 days of react design pattern going guys if you are taking this course I'm putting a lot of effort believe me lot lot of effort I would love if you can share a few words about it in the public if you can tell people like something like this exist so that more developer who really wants to learn and want to grow senior not you know in terms of years and the age but by experience of handling react project

20:50 for them this will be immensely useful and making something out for free. I feel really proud to giving back to the dev community and if dev community also can help me to spread the word about it that will be really great thing. Thank you guys. So let's move on to the next one which is use memo. All right coming back to the use memo. So here is a simple demo. Okay, don't look into this name too much. I have used the same name. You can use many random names you know for your demo. So what is happening basically again the parent child relationship and the components and all.

21:19 So the parent component is having this number and the increment just like before a count. So if I click on this this number gets incremented that's it. And the child component has a sorted array and listed each of the name from the sorted array. Right now I have listed about thousand you can make it like 10,000 100,000 1 million whatever it is consider it's a big big big array. Inside that array you are performing sorting mechanism or sorting algorithm. Now what happened due to our parent child relationship and how react works.

21:52 We know that if the state value which is the zero of the parent component changes it is going to force this child component also gets redender over here. If you see on the first render user component redender it is coming from this particular sorting thing. This is the user component. Now if I click on the increment once more I can see the user component red happened once more. If I click again, if I click again, if I click again, every time I click, it is going to happen. Coming back to the code, this is my parent component where I have that button increment button. And as you have guessed, there is a count state. Clicking on that increment button, I am setting the count by incrementing it value by one. That's it.

22:32 That's what I'm that's all I'm doing. Now, I also have this child component where I'm listing all that usernames. And the usernames are coming from a method called say get user that I have written in my utilities there. It can return 10,000 100,000 usernames. Okay. And this users is what I'm passing as a prop to my users component which is a child component. If I go to the users component, it takes this prop. It put this console.log. That's what we have seen. User component rendered whenever the count gets incremented. But here I am doing an operation. I'm sorting it.

23:03 and then the sorted user I am putting over here simple simple component but there are lot of problem in the line number four the first problem is I'm sorting this array which is a huge list of user object for example now if it has say 100,000 user object this is going to make this sort every time this component gets rerendered so that's the first problem second problem I am actually mutating the original list of user right which may create certain issue because ideally I should be creating a copy of it and then only do the sorting as I am sorting the large data and this is just getting rerender on every button click or say every key down it takes a lot of time to process the sorting right so that slow down my UI and we all know if the parent renders child renders so sorting happens every time now this is not a great use of my energy and time to have this kind of sort going Though we have taken the

24:04 example with sorting but there are other such functions like filtering running any kind of expensive computation formatting heavy data doing object or array transformation that produce new functions new objects new references all are going to create similar kind of problem and that's exactly where use memo comes in. Use memo helps you to cache the computed value until its dependencies change. Use call back. We have learned that what it caches the references until the dependency changes. We have seen it with function. Use memo cache the value until its dependency changes. Imagine use memo as something which memoize the return value of the function and it cach it. It always return you the same value if the input remains same. If the input changes, it is going to return you the change value and again cache that value so that from next time it can again return you the cache value if the input doesn't change.

25:01 Now the same code we can change with use memo pretty well and pretty easily. For that purpose, first thing first import use memo from react. Let me comment out this sorted thing and let me write the logic for sorted using use memo. So I'll have use memo. This again take a call back function and just like use call back you can pass a bunch of dependencies over here instead of mutating this list directly how I was doing before let me first create a copy of that list using the spread operator and on top of that I can do this sorting logic so I'll be just copy pasting this one and this is going to return me new sorted array that's I'm going to return and as and when the list changes I am ready to do this computation if the list doesn't change I'm not ready to do this computation so you understood use memo is a hook that takes a function and a dependency array that dependency array decides when the input changes then only

26:03 whatever you have written inside this callback function has to execute otherwise it won't so what execution we are doing if this list changes then only it makes sense to sort it again and then the return value will be over here which we are already using to map it out Great, isn't it? All right. Now, let's go to the UI and see what's happening. So, first time on the first render, it says the user component rendered. Great. Parent rendered and child also rendered and it's sorting the expensive list. So, first time the use memo got called because list the value of list supplied for the first time to the child component, the user component. Now, if I increment, what happened? If I am incrementing, I'm saying that user component rendered this log I got.

26:45 However, this sorting expensive list log has not come. That means if I keep incrementing, of course, my parent component state value changing. So why my child component is also getting rerender? Because child component I have not memoized. Enter component I have not used in this case inside the memo higher order function. So it will definitely rerender. But even if it is rerendering the heavy computational logic, the sorting logic that is not getting executed. See I'm incrementing incrementing only first time it came sorting expensive list but rest of the time it is not coming. So if I go to the code again this will be coming every time because this child component is getting rerendering that's fine I'm completely fine with that but this computation is not happening again because this list is quite static that's what I have got from my utility function if this list changes only then it will

27:37 be recalculated again and only when you will see this console.log log once again. So for any kind of such expensive operation, it's always good to use use memo. Now again the catch over here is please don't use use memo for any smaller computations. It is not going to save you much. See even to look into like if some value is cached and then only return the cache value or return the new value, it requires certain computation within React is computing something at the background, right? Now for a smaller calculation like like for 5,000 10,000 values why would you do that? If the value really grows where your application performance the search the button click adding to the cart something is getting very much sluggish only in those cases think about using it. Don't use it just because it is there sometime eagerly optimize the performance of your application may introduce more performance bottleneck.

28:28 So you have to be really careful where you should be using where you should not be using. So I hope the memorization technique is quite clear to you. Now let us talk about the second technique. Can you sense what is wrong here in this code? So this is a simple cart component. What I'm doing basically I'm taking the number of items that are there in the cart and then computing the total number of price that somebody has to pay the total amount somebody has to pay to purchase the item there in the cart. And then I'm just rendering that total value over here. Very simple. I kept this use effect over here to calculate the total sum the total amount that somebody has to pay and that's how after computing the amount I'm just changing my state variable and this is what is going to reflect over here is there a problem that you see in this code if I run this code it will beautifully run if I just pass an array

29:20 of items with their price it is definitely going to run and give me the total rendered on the component then what is the problem the problem here is with something called derived state that's another thing that cause a lot of performance problem if we are not careful. What is a derived state? Derived state is any value that can be computed from existing state or props. Okay, again I'll repeat a derived state is any value that can be computed from existing state or props. For example, you have a list, you can derive the filtered list from there. You have the cart items, you can derive the total amount for the cart. You have a text, you can derive the length of the text.

29:59 you have a boolean you can derive the enable disabled states from that derive state should not be stored in another react state. This is a problem I have seen tons of time whenever I reviewed code in my life. Derived state again the rule derived state should not be stored in react state. Why? Because storing it cause unnecessary renders which is the cause of many problems in terms of performance of your react application. Secondly, if you are storing derived state as another react state, you have to synchronize between the original state versus the derived state. What if your original state becomes still your derived state still out of sync? You have to do lot of complex logic sometime to manage the synchronization, right?

30:44 And always you're doubling down on the rerendering whenever certain updates happening. Why do you want to do that? So that's exactly the problem over here. Now if the same cart component I have to rewrite as a better cart, it will be much more simpler. See how it is. I'm getting the items from items using the JavaScript reduce method which is the exactly same logic that I have used over here. I am now computing the total and then rendering the total. That's it. Whenever the props change this value will change. Why? I have to do another use effect. I have to manage another state another derived value for this as a state and use it. Now there is no basically unnecessary things happening over here. Right? I have reduced the load a lot. I have written very very less number of code over here. So this is an antiattern storing derived state in use state what we have seen over here. Please stay away from this. Now

31:38 here is one more example. Tell me whether it's a good example or bad example. I have the users component. I am taking a list of users and then I am filtering this. Maybe this list contains 100,000 users. So of course I have used use memo. By now you know why we used memo. is a expensive time-taking computation. So as long as the user list stays same, I don't want to filter them again and again. So it filters filter out only the active users using this user.active. This active users get returned and I'm using active users over here as a map. Is it a good practice bad practice? Now first thing you need to answer am I using any derived state? No, because I have not declared anything with use state and this particular guy whatever I'm using in my JSX is not a state because to make it as a state either I have to use use state use reduc or things like that I'm not using it's a simple variable that returns a heavily

32:32 computed value. I'm using use memo because I care for it because my list may have 100,000 1 million users. So active users now has computed heavily computed user value and then filtered user value. Active user value and then I'm just rendering on my JSX. That's it. Simple. So no derived state. It's a good way of doing things. However, this one of course this is wrong because I get an age. Then again like before based on the age value I am checking whether the age is greater than equals to 18 or not. In that case the person is adult. So I have a boolean value is adult and based on that I'm saying adult or minor. I don't need this computation inside use effect.

33:09 I don't need this derived state. I get the age. I just have a variable called const is adult equals to age greater than equals to 18 and then use is adult directly over here in this condition. That's it. Correct? So no derive state no drama extra drama in your code. This is another one I have seen in terms of form. This is taking name and email. I have to validate it. Why would I create again a state called is valid? And again why I use is effect unnecessarily. Whenever the name and email changes I am marking as whether the is valid is true or false and based on that I'm taking a call. No don't do that rather create a variable called const is valid equals to this particular logic. So whenever name and email prop changes that will be called and then is valid you use as it is. That's it. No derived state at all.

33:59 So these are some of the practices I hope that you keep in mind and I hope you understand why derived state is bad and how you can get rid of it as much as possible. Now let's go to the next technique. The next performance technique or the pattern that we're going to talk about is called the bouncing. Now again if you are someone who is following me and following 40 days of JavaScript you know that I had a session on performance optimization of your JavaScript app and there I have explained debouncing and throttling and concept like that visually right now I'm going to explain it over here also but let's see the problem first. Let's imagine this is a portal where I can search user and this makes an asynchronous call on an API fetch the data over the network and display the search result the match result at the bottom. I have not implemented that ent but I've implemented it so far so that I

34:51 can show you the demo. So here as and when I type something like tapas if I type on my every keystroke you can see a console.lo block appearing over here which is given at the place where I'm making the API call. So if I type T A P A S if you see that I have made a API call with T A T A T A T A P A S it means that for every key stroke I have made an API call now this API calls are not cheaper they are costly they are expensive why they are expensive because you have to make them over the network and then some of the API calls may have rate limit you probably have to pay for those API calls once you pass the threshold so you got to be very sure that you are not going to call this API so rapidly rather you need to have certain mechanism where you can actually control this. This is where debouncing come into picture. So what debouncsing is debouncing is a technique through which you can delay the execution of a

35:49 function by certain time. Okay. Now one thing you have to remember over here whenever I'm typing something on my input text box I am actually generating triggering an event that is what onchange event now through debouncing you are not controlling that event you cannot control that event the event will happen the onchange event will trigger but due to the onchange event triggering you were calling certain function of the API you can control that okay some folks they get confused with oh debouncing means I don't trigger the event at all.

36:23 No, event will be triggered. But due to that event trigger, there used to be a function call. That function call will not happen for a specified time that you decide what is the specified time. All right. So this is what the debouncing as a whole. Now to implement this debouncing in React, we'll be creating a hook and I'm going to explain the code in detail. But before that, so far look into this search component. The search box component. As usual, it has a state called query. Query means whatever you are typing inside the search box whatever the value that you type inside the search box that value set inside this query variable and you update the value every time somebody type on this input type text box using something called onchange right this is change event and using the set query updator function whatever the value there inside the input box you set as a query and your state value gets updated you have a

37:14 use effect we all know what it is it has a dependency called the same query so it means that whenever the query gets updated let's make an API call and here we have simulated an API call like fetch call I don't have the call in in real just assuming there is an API so what is happening every time I'm key in I'm changing something this query gets changed and this use effect gets executed I'm seeing this API call with this query every keystroke now my intention would be I limit that I don't make this call I don't make this one executed for a specified time delay For that purpose I have now a hook called use debounce. This takes two parameter very important. One is a value which basically influence the change of the query. Basically that's the value and there is a delay that I specify. Here I have put a default delay of 500 millisecond. You can put the delay whatever the delay that you want. Now if

38:09 a delay is passed from outside this will be overridden. This 500 millisecond will be overridden. If it is not passed from outside it will take the 500 millcond. The best part over here is this guy. This is the heart of debouncing. It's called set timeout. What does set timeout do? Set timeout deferred calling a function for a specified duration that you provide. So here set timeout will defer running this function for this amount of delay that you have given. Now what is this function doing? This function is setting something called debounce value. That's exactly with the value that I have passed to this use debounce. And this set debounce value seems to be a state. So it means that if I do set debounce value over here, it is nothing but setting this particular value which I'm ultimately returning from here. Okay. So it means that even if the value comes over here, the return value from here is happening only after

39:00 the delay that I am specifying. Okay. So I am actually giving you an updated value back only after a particular delay. That's all this use debounce is doing. Once this delay expires then I am again giving you the updated value. Until the delay expires I am not giving you the updated value because until this delay happening this particular function is never going to get called. If this function is never going to get called this debounce value won't be set with a new value and you won't get a new value as simple as that.

39:33 Also please notice in this user fact I have a cleanup method called clear timeout. Whenever you are using something called set time out or set interval, you have to ensure that you clearing them as well. Okay. Now, use debounce is what I got. Now, how can I use it in my search box? Let's see that. So, first thing first, let's import use debounce. I have imported use debounce. Call is debounce over here. Pass the query and I'm passing a new delay. Now, if it takes this query, this query is again what? Whatever I'm putting inside the input box. So every time I put something like I put t I put ta I put t a p every time I do that it goes to use debounce as a value and there is a delay given till the delay is there it is not going to get set with any of the value that you're passing here not with t not with ta not with tap as it is not getting set with any new value the value that you get from here is always the old

40:29 value now once this is get expired that point in time whatever the value you passed with that value this debounce value will be reset and it is returned. Okay. So that value come over here and now everywhere that we used query instead of that let's use debounce query. See so that's all the code is right. So now instead of query I'm using a debounced query which is a result that was created out of the query itself but after a delay whatever the accumulated query I got I am returning only that and so the output of this was also changed before for each keystroke I used to get that I'm making an API call now I won't get that I'll get it only after 600 millisecond since I last type so if I type a a a see I'm not getting anything on the right side Now I'll get a 600 mcond pause. Yes, I got it again. E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E Now 600 see now difference

41:27 first it has taken where I stopped all the A's. Then again where I stopped A E E that's what you have right so instead of making an API call how many A are there probably eight A's and four E instead of making 12 calls over here I'm making just one call that's a huge performance bone if I keep typing things also see I'll make just one API call over here but before without that I used to make API call for each of the characters that's a huge performance boon don't you think so this is what debounce does for us guys so that's another technique the last one is about throttling last one means since part one's last one. Okay, part two have lot more to cover. So in the part one, we're going to talk about throttling. First, let's see the demo. So I have a bunch of items on this UI and again look into the right side console.log. What I'm going to do now, I'm start scrolling this one and this is going to show the scroll

42:18 position. That's not very important. But in the right side, if you see how often I'm making some DOM manipulation. Okay, I'm scrolling very slowly. You see, I'm scrolling very slowly. showing actually the scroll position over here four five but this one almost 28 times it got rerendered almost 28 times I made a do manipulation now see it is going to increased and very slowly very slowly I'm scrolling it's increasing as the scroll y position is increasing as the scroll y position is increasing I'm seeing this guy also getting increasing now imagine if you are doing certain painting you're doing certain dom manipulation calculation and every scroll movement if you are doing it minute movement of your scroll position and if the DOM computation manipulation is something which is bit heavier this is not a good thing to do that's why throttling come into picture so what is throttling debouncing where we can defer

43:14 a particular function execution or the value generation for a certain period of time we can delay it the throttling is little bit different in throttling we say that within a specified span of time I want certain things to happen at most once once the span is over time span is over again I can make it happen that's a very big difference between uh debouncing and throttling however many gets confused let me just reiterate again for everyone's sake debouncing is delaying an execution of a function or getting a value out of something for a specified duration so for that duration a particular execution particular operation is not going to repeat or take place however for throttling for a particular duration a operation is going to take place but it is going to take place at most once that's the difference now here also we'll be using another hook called use throttle and the logic is pretty simple over here as well what

44:11 I do we get that value that we want to throttle throttle means this particular value is going to change at most once within this particular time frame if I pass a bigger time frame from outside of course it will take that what I want to track over here when this value was last changed. Okay. So we track it with last executed something called which is called dead dot now when it got last changed and here we are computing that right now whatever the time is which is right now and when it was last change the difference between these two whether it is greater than equals to the delay that I have specified. Imagine if the last change happened on say 10:00 and the next change is happening at 10:15 that means there is a gap of 15 minutes in this computation. Now if I have given a delay of 20 minutes this 15 minutes has not crossed the 20 minutes delay. So the function call is not going to happen. The new value generation is not

45:08 going to happen. If this delay is say 10 minutes but this difference is coming 15 minutes that means I have already crossed my 10 minutes delay. So I'm allowing the recomputation of this value or the function call again. That's all guys about throttling. This is the core logic of throttling. Nothing more than that. So it means that if a value get passed, I'm actually throttling that value for this duration. Once the duration is passed, I'm allowing it to set a new value and the new value the throttle value is what returning from here. This is what the use throttle hook is. Very very simple JavaScript logic basically. Now to make it work pretty simple. I have to first import use throttle over here and then instead of having this scroll y value which I'm showing over here right let's do one thing let's use the use throttle pass the scroll y over here and pass this a big time a large time maybe 3 seconds

46:04 right and this throttle y value instead of scroll y we'll be using over here now let us go to the UI refresh this refresh this now I'm going to scroll down slowly again see I'll start scrolling I'm scrolling okay I got after 3 seconds see it is not coming on my every scroll look at the time I'm scrolling look at the scroll and the things coming at the right side is much much reduced right now correct so for every scroll it is not coming it is coming only after every 3 seconds it is happening only once so my DOM manipulation has reduced a lot so as promised we have covered memorization derive state debounce and throttle we also spoke about rerendering and the problem due to that in the next session the part two we are going to cover the splitting components methodology virtualization going to talk about the context optimization and also about the react compiler however you know that none of our session gets over without a

46:58 task right this session even know even though it's a part one has it task let's take a look into that okay so these are the task of your part one fix the broken memorization take a look into this particular code and the task is to make sure the child renders only once Even after repeatedly clicking on increment, I have showed this already, right? So you can fix it easily. Then improve the derived state antiattern. I have a filter thing and I am just doing this state changes based on something. So you know that I'm not giving you hint. And then build a small dashboard basically a search bar with debounce a scroll tracker with throttle. I have showed it and then the user list with a 10k or more filtered by search no derived state with performance optimization. all the techniques that I have showed using that just do this very simple once you do this task I'm sure that this learning is going to go inside your brain and you

47:50 are never going to forget it all the code will be inside day 11 folder come to performance patterns come to the src performance folder and then you have memorization debouncing rerendering you know derived state throttling all this whatever examples I've covered everything over here you know how to grab it you have to go to github.com/tubberscript Please follow this because I keep sharing a lot of awesome repositories over here and then you can go to 15 days of React design patterns. Once this video is published, you will see day 11 and all this code that I've showed over here will be there. Also join Tapascript Discord where you can talk to other developers and we also can talk sometime and discuss things. Okay guys, stay tuned for part two and show your love. Please subscribe to Tapascript. Spread the words about the thing that I'm doing. That will be great help. Thank you. Take care. Hey. Hello

48:42 everyone. Welcome back to the part two of React performance mastery. If you like the part one where we spoke a lot about rerendering, memorizations and all things around it, part two is going to be a lot advanced. Though is advanced but you don't have to really worry if you are just a beginner to react. We are going to go through each of the use cases, problem with lot of examples and easy to understand language so that you get the entire cracks of it and you'll be able to utilize and use all these things that we'll be discussing in this video in your day-to-day application.

49:20 Excited? Yes, I am also very excited. If you're coming to part two directly, one request would be first finish the part one and then finish the task and then come to part two. You know if you want to learn something deep, if you want to learn something well, there is no shortcut to it. Take some time, give yourself some time and that's how you learn things better and you learn thing one for all. Let's check out what's there in part two. We have already learned about memorization, derive state, debounce, throttling etc. In part two, we are going to learn about how splitting components logically can save a lot of time and can boost the performance. What is virtualization mean? where to use it, what are the benefit and how we can do and how we can gain on performance because of using this technique. We're going to talk about context optimization. What is context? We know about react context but

50:11 how can we optimize it. So there are certain rules and technique. We're going to talk about them. We're going to talk about React compiler. And apart from these four things, I'm also going to talk about a few great practices that you can adopt while programming in React so that the performance concern is taken care from the first line of the code that you'll be writing for your project. And as usual at the end I will give you certain task and assignments that I always encourage you to do because once you do those task and assignments after taking the session your learning is going to be solidified and you are not going to forget the things that you're learning out of this you are spending some time right out of your life let it be of a great use. React 19 introduced something called React compiler which automatically memorize components, stabilizes the function references and prevents unnecessary rendering without

51:06 requiring any manual effort from developer in writing use memo or use callback. In part one, we have learned about react.mmo, use memo, use callback. All these utilities only purpose of those utilities were that they save you from unnecessary rdering. Until unless a dependency changes for a component, your component is never going to rerender, never going to execute a function multiple times, never going to recalculate certain values. But for all those things, we had to provide react.mmo, use memo, use callback, all these things with our hand by code, right? But now what we are saying as react 19 got react compiler in it we really don't have to write react dome use memo use call back all these things this is huge don't you think it will reduce a lot of code lot of boiler plate and a dozens of accidental performance issue in the part one I emphasized about one fact use memo used callback are

52:06 great things but sometime we overuse them we kill the code and now what react is promising if you use React Compiler, you don't have to use those things by yourself. That's great. Now, if we draw a comparison before React 19 and after React compiler came into picture before React 19 developer had to manually optimize things using use memo, use callback, React dome, right? You remember we spoke about it that inline objects and the functions can break memorization. That's the reason we were using use call back and all this stuff.

52:41 And the other problem was with every render the values were getting recreated. So if that value was created out of a heavy computation it was too much to take care for a component. Now after react compiler came into picture the best thing that happened component outputs get memorized automatically behind the scene. Functions get stabilized automatically behind the scenes. You as a developer write less code and React optimizes more. So what does it mean to you? I'm sure you recognize this code isn't it? I'm using the use memo hook and consider just assume that there is a heavy operation happening over here until unless the value of amount changes. I don't want this amount multiplied by two to be recalculated. So I'm caching the result as long as the input to this is remaining same. I'm not going to recomputee it. I was doing it because I assume that multiplying by two of this particular amount is a heavy operation

53:37 just for the example sake. So I don't want to recomputee this again and again as long as the value of the amount remains same. Now this is the old way. Let's write it. This is old way. Now what will be the new way? If you use react compiler, how will you refactor this code? That's all. That's all you're going to do. There is no use memo at all. You have the amount you multiply by two and you assign to a total variable as you were doing before. You remember as you notice I'm not using use memo. I'm not defining what is the dependency of the use memo. I'm not telling React anymore when to cache, when to recalculate a thing. React will take care of the things at the background for me. I don't have to really do anything for this. Configuring React compiler on your React 19 or 19 plus React codebase is pretty straightforward. The only thing you need it to install this dev dependency. You have to install Babel

54:32 plug-in React compiler. That's all. That's the only thing you need. As I'm using yarn, I'm using I'm installing it using yarn at command. Minus capital D stands for the dev dependencies. If I install this after a successful installation, I will find it over here in my package.json file. And then I have to do one simple configuration in my configuration file. That configuration depends on what kind of project environment you are running. I am running this React application in a Vbased environment. You can see v.config.js file over here. If you are running on Vidbased environment, there is one kind of configuration. If you're running it on a Babel based environment, one kind of configuration. If you're running on a Nex or React router DOM, for everything, there are different kind of configurations. Each of the configuration steps are very well documented on React website, React documentation, you can take a look. I

55:24 have also provided the direct link to that in the description of this video. Now, if I take a look into what kind of configuration I need for Vbas project, it's pretty simple. You remember you just now installed Babel plug-in React compiler. So the v.config.js file has given a definition of that same plug-in over here. Ideally, originally you will find your vid.config.js file like this. There won't be any argument passed to this react. Now what I have done is just passing this particular argument that this is a babel plug-in and the plug-in name is babel plug-in react compiler. the same thing that what we have installed. That's all you need to enable React compiler on your React 19 or React 19 plus project. Now what does it mean to us? We have done all this thing. How do we know even that this is working? For that, let me first run the server locally. So it's running on local host 5173. Let me go to

56:19 browser. Don't worry whatever is shown over here for a moment. But if you open up your dev tools, if you have installed react dev tools extension for Chrome, Firefox, age, whatever browser, whatever your favorite browser is, just install that extension react developer tools. In that there will be something called components. If you come to components, you will see that your entire hierarchy, entire component hierarchy having a tag called memo. You see that beside everything is called memo. This means that the React compiler is now activated on your entire component tree and each of your components are automemorized.

56:56 You have not done any use memo. You have not done any use call back by yourself. This is automemoized. Okay. So this is how you can figure it out. Now you don't have to use use memo. You don't have to use react dome. You don't have to use use callback. Your entire application is memorized. But sometime what happens? You might want to opt out from memorizing your component automatically by React compiler. On that case, you can use this directive in your component. Inside your component, you define a component using function, right?

57:27 Functional component function. Then the component name inside that you can use this directive called use no memo. If you use that, then this particular component will temporarily be opted out from the optimization of React compiler. Now when you should be doing this if you find that there is a problem with this component using along with the react compiler only in that case you will be opting out but in most of the cases the recommendation is if you're on react 19 and above don't use this one use and activate for the entire project see if you're facing any issue then use this particular directive isolate this component out of your React compiler perspective fix the issue and then remove the directive I hope that makes sense. to you. Now having said that if you want to understand or take a deep dive of how React compiler works internally in general if you are from computer science and engineering

58:22 background you must have learned about compiler. You must have understood compiler in your academic years. Now how the phases of compiler are related to react compiler and how react compiler take your component code what it does what kind of translation happen internally so that it can improve this performance if you want to get deeper into it I have created a video for you already so please take a look into that video also I have written a complete guide and published on free code cam some time back you can take a look into that resource as well I have given a link to both of them in the description of this video so that you find it handy and you can learn from it. So that's about React compiler which can really make your performance boosted for your application provided you're on React 19 or above. Last thing, React compiler best used with React 19, it can still work with React 17 and 18. In case

59:17 you're still in React 17 and 18 and you want to utilize React compiler with it, here is something simple and realistic for you. React compiler is not a magic. While React compiler gives a lot of things automatically help you writing lesser code but you still need to optimize a few things. You still need to know how to optimize a large list in your application. You still need to know how to optimize context value. You still need to know how to do component splitting correctly. You need to know how to do lazy loading. You need to take care of something called virtualization.

59:50 You need to know about what suspense means. You need to know about the concurrency and the transitions. All these thing come together along with the optimization of React compiler to give you the best thing about performance. And believe me, there is nothing that you have to do extra. There is nothing that you have to do special. You just need to follow certain good practices, standard practices when you are thinking about coding in React. When you have a use case and you want to translate that into your component before well before you start writing your first line of code for the component please take a pause think about the use case that you have in hand for example do you have a long list of item to render all the data came from the server to the browser and you have to tackle this large list you have to do certain lazy loading when you have to do certain kind of transitions all this thing is what you need to think

1:00:39 prior before you start writing your component so in the next section I'm going to introduce to you about code splitting and lazy loading. Big application means big bundles. Big bundles means one application you have you have written the code you have to build that application so that you create certain bundles certain artifacts that you deploy on a server and then on a public IP your customer can access that deployed artifacts that's your application. So when application gets bigger the bundles get bigger and once bundles get bigger wherever it is deployed to from that place it has to be downloaded on your client's browser. Now depending on the network latency and everything the download might really take certain amount of time. So it means your application may get slow startup.

1:01:26 Lazy loading allows you to load only what is needed and when it is needed. It improves time to interactive. That means that when user click on something the interaction point the perceived usability of that element will be much much faster reduced bundle size and as I was saying because of these two perceived performance increases. Now let us take some example to understand how lazy loading works with lazy loading without lazy loading what is the experience that our end user gets for an application. All right, let's talk about two components. One is called light.jsx, another called heavy.jsx. What light do.jsx is doing a very simple react component, right? It has a simple console.lo, you can ignore it. But what it returns, it returns a div which is having some kind of style and then it has a h2, it has a paragraph, a presentational component which we sometime call as a dumb component also,

1:02:22 right? It's a component that's name is light. It's a lightweight component. Along with that, we have another component called heavy component. Okay, heavy weight component. What does it do? Let's see. The heavy component does a heavy computation. It generates some big data. You know, maybe a array of this many element. You know, as operation is heavy, we are using use memo. Why we are using use memo? If you're coming from the part one, you know why we are using it. So, we get the data. After getting the data, we are rendering the data's length and then certain textual elements. That's what we are rendering over here. So, this is what the heavy component is doing. Now let's take a look into a component called non- lazy loader. So this is my demo about a component hierarchy where lazy loading is not used. I have imported both light and heavy. In the non- lazy loader I'm using this light. As you can see there

1:03:13 are of course few textual information and then I have a button. Whenever I click on this button I toggle a state called show. Show hide. Show he hide like this. So whenever show is true only in that case I'm showing this heavy component. So it means that if I now render this non-lazyl loader jsx from my app.t JSX file I will see this bunch of text I will see a bunch of text coming from light I will see a button if I click on that button first time I will see heavy if I click on it again I will hide the heavy that's what this particular component is doing but there are lot of story happening in the background let me first open up the application on browser let us first see what is happening yes non- lazy demo of course a bunch of text this is coming from the light component and here is a toggle if I click on it it toggled And I saw this one is getting rendered. If I click on it, it will be hidden. Show

1:04:05 hide. Show hide. All grid. Now let's go to the developer tool using F12. And let's go to the network tab for a moment. Let me reduce it little bit so that I can capture everything. And now I have this disable cache mode. That means nothing is cached. And I want to throttle this to say slow 4G. Okay. Now what I'll be doing I'll be just refreshing this one but before that I'll select all as a filter. Okay so that everything gets captured and let's refresh this one. So you're seeing things are coming it will be slower because I'm running on slow 4G. Light is taking some time. It took around 2.52 millisecond. Heavy took around 2.57 millisecond. And then after light and heavy both got downloaded I am getting this entire UI getting rendered. Heavy is something where heavy computation is happening. Okay, I'm using react memo but react memo will be impacted only from the second time. First time when it

1:05:04 is rendering the calculation has to happen even if the use memo is there right on the first render. So on the first render I am blocking the rendering of this entire component until I downloaded light and heavy completely. But have you noticed this heavy the output of the heavy component the rendering part of the heavy component I need in my application only when somebody click on this show heavy then only I'm showing the rendering part of the heavy component unless somebody click on this show heavy I don't need this heavy component on my UI at all then why am I downloading the content so much thing from this heavy.jsx JSX on the browser. Why am I putting this unnecessary load? Imagine somebody is in a slow 4G network. That person is going to see a wide screen. Still nothing is there. See this heavy is spending light is spending. Now once heavy came up, still it is processing. Now it got it.

1:06:00 So this is completely unnecessary. Right? This is why lazy loading can come into picture. So as you can guess correctly now with lazy loading I can now lazily load this heavy component because the rendering of this heavy component is not required at the first shot of rendering of this enter component. The rendering of the heavy component is required only when somebody click on this show heavy then only I can go selectively fetch the heavy component load that heavy component and then render that heavy component. that reduces a lot of rendering time on the first load and then improve the user experience because I can now additionally do like a loading state when somebody first time click on this show heavy while I'm downloading this particular component lazily and then attaching to my component hierarchy till then I can show certain kind of loading indicator I can fall back to a loading indicator till the component is

1:06:54 completely ready for me that's where I'll be using something called lazy loading along with suspense. Now can we see instead of non-lazy loader.jsx a lazy loader.jsx. So in non lazy loader.jsx we had imported light and heavy directly. But now I know heavy is something that is coming only when user interact with the link. It doesn't need to be there. It doesn't need to be downloaded at the first shot. So I'm using something called react.azy. This comes from react itself. You can also do import lazy from react or you can write react. lazy directly. Now here you pass a function. The return of the function should be an import statement where you pass what you want to lazily import the path to that. So here I'm saying I have a component file called heavy. Please import that particular component dynamically and as you're importing this component dynamically I'm passing that to react lazy so that it takes care of

1:07:50 it lazy loading and it gives me back this component which I can now place conditionally somewhere where I want this particular component output to be lazily rendered so far with me rest of the pieces are exactly same just like before I have a state called show and hide for showing and hide just like before I have this H1 I have this P just like before I have this light But I have now introduced something super exciting something called suspense. What does it do? Suspense come up with something called a fallback. And it expect certain thing to be rendered as synchronously.

1:08:23 It means whenever this guy show whenever this show is true I am going to show this heavy isn't it? That's my condition. This heavy was not imported like light not statically imported. It is dynamically imported along with lazy. Now to render that you need something called a suspense along with a fallback saying that till the point this content of heavy gets downloaded and fully get begged and rendered on your browser show something in the meantime. So it means when someone click on this button set the state of show as true react will start importing this heavy downloading the content of it on the browser baking it and rendering it. Till that point in time suspense will show this particular div saying that loading heavy component and once this guy is ready to show ready to render this fallback will go over and we will see the content of heavy. What are we achieving by doing this? Of course the first thing first when this

1:09:24 component lazy loader component gets rendered it doesn't render heavy. It it just render H1 P and light. That means I'm not downloading the heavy component. I'm not downloading the content of the heavy component. I'm not doing this extra rendering. When someone click on this button being reactive then only I am downloading the heavy component. Then only I'm importing the heavy component, downloading the content of the heavy component, rendering the heavy component. Till that time I'm showing a fallback as well. This is the change.

1:09:54 Can we see the output of this? So before I show the output of that, let's take a look into one more thing. when I'm refreshing that just take a look that both light and heavy is getting downloaded well before I click on the link in my previous non- lazy version correct both light and heavy is now downloaded now I'll go ahead instead of non- lazy I'll import the lazy version of it and I'll use the lazy loader part of it okay now let me go back to the UI I'll clean it up I'll refresh it now see the magic see things over here okay getting downloaded Light is getting downloaded. After light only I see this UI got downloaded. I don't see heavy here at all. I used to see heavy here along with light in my previous example because light and heavy both were statically imported. Both were getting loaded when this particular component was getting rendered. But now as heavy is dynamically imported and dynamically

1:10:51 rendered based on this condition of clicking on this show heavy until unless I click on show heavy I don't find heavy at all and that's the reason this particular UI in this time even with slow 4G disabled cache came up much much faster because the heavy computation was not getting done in the background. Now what I'm going to do, I'm going to clear this up just to show you that when I click on this show heavy that time I'll be able to see that heavy. JSX coming over here. You want to see that I'm clicking on show heavy. Right now you see heavy. JSX. Now you saw heavy. JSX and you are also seeing the rendered part of heavy. JSX. Now if this heavy.

1:11:30 JSX is making an asynchronous API call getting the data doing lot of computation on this till this heavy. JS is getting rendered completely attached to the component tree. You would have seen that fall back as it is very much in memory and a very small component. You are not seeing that fallback message is happening very fast. But you got the point right without lazy you are downloading everything. There is no separation in terms of performance. What is heavy? What can I download dynamically lazily now with lazy and suspense you have that entire content. I hope it was helpful. Now let's talk about another technique called component isolation. Now this is a good practice part than a pure pattern because the pattern of this we have covered in part one already which is called memorization but a good practice that want to highlight. What we know we know react rerenders children automatically when

1:12:21 parents render but with proper isolation we can prevent this. Here is an example which is a bad example. What do you see over here? There is a dashboard component which take two props. One is user and other is statistics. It uses three child component. One called user card. Another called revenue. Another called visitors. The user card use a prop called users which uses this particular value. Has a prop called stats which you which uses this stats value. Visitors doesn't have any prop. Now in this situation if the value of the stats changes this dashboard renders all the children redenders even the one that doesn't depend on the stats directly. Right? User card is going to get rerendered. Visitors also going to get rerender. Now how can I rewrite this example little bit better way to save from this rerendering? Let's see a good example for this. The good example for this would be this isolated dashboard.

1:13:16 Here also we have imported this revenue user card visitors. But as you see I have used memo from React passed this component all together the user card and the revenue which are props dependent and got a memoized user card memoized revenue and now I'm using the memoized user card memoized revenue because of this isolation what happened if the stats changes now only this guy gets rerendered this is never going to rerender because user the input to this am user card which is a memoized version of user card is never changing so it is memoized, it is cached, it is not going to rerender. So we have learned this technique of memorization in the part one. I'm just showing certain good practice of how you can isolate components with memo so that it create certain amount of render boundaries and that's a pure win. I hope you find this useful as well. By the way, are you finding it helpful? If you find this

1:14:08 helpful, especially the part one, part two, you should look into my full-fledged course called React Design Patterns, 15 days of React design patterns, which is available for absolutely free, taking you through all the important design patterns that you must know in React and apply them on my YouTube channel. The link to that is in the description of this video. All right. So, the next one we are going to talk about context optimization. What is context? We know react context is pretty powerful but can cause massive rerender because it forms a chain right you create a context to provider you provide the value now wherever you want to use the context in your component hierarchy you can take the value out and you use now something somewhere change can't read your entire component hierarchy which providers have wrapped so you have to really be mindful of how you can optimize your context Let's see one

1:15:04 example for that. Can you tell me whether this is good or bad? Let me explain this to you. I have created a provider say user context provider. Now this is coming from the user context and I am giving value means I'm providing value. One is the user data another the theme information of my application and what it is wrapping it is wrapping my entire application. What do you think it is good or bad? I would consider this as bad example. Why? Because it is using one big fat context. Imagine if theme changes all the components that is consuming user also redender. Now if the user changes all the component that is consuming theme is going to get rerender. Now if these two values are something which is partially be used inside your application component hierarchy you won't be passing things like that. So what is a good practice?

1:15:55 The good practice would be splitting the context. Now the same example you can consider writing in this way like you split them as user provider, you split them as theme provider, you wrap the part of your application tree where you want to provide the user information, you wrap the portion of your component tree where you want to provide the theme provider, right? It not necessarily it has to wrap the application. It can go inside the application and can wrap a particular portion of the component tree where you want to provide the user provider. Now the first level of optimization that you can do is first split the context like I have splitted the context with user provider and theme provider separately. Here I was passing the user value and theme value one big fat context provider. Don't do that.

1:16:42 First is split. Second thing be mindful whether user provider theme provider need to wrap the entire application or can I now go one more level down identify what is that portion of my component tree that only require my user provider or my o provider or my department provider whatever it is wrap only that portion theme provider might be something that should wrap the entire application okay great but user provider may be something which should not wrap the entire application maybe the part of the application so This is another optimization technique that you have to make sure that you keep in mind because context is something that can leak lot of performance issues in your application if you're not mindful about splitting them and use them contextually. Have you seen some UI that renders like say 100,000s list elements and once you start scrolling them you feel like very sluggish is jank. Virtualization is a

1:17:39 technique that solve exactly that by rendering only what's visible on the screen. Okay. And then again when you scroll it further you can load the next set of item. Again you scroll it you can load next set of item. So when you do virtual scroll when you do pagionation on those cases virtualization is a thing that you must keep in mind. See the thing is like what you show to the user that's visible to your user. Why do you want to unnecessarily bring things on your browser, load your browser memory that are not visible to user? Once you want to make certain items visible to your user, again bring that to your browser, occupy your browser memory and make it visible, make it render for your user. So that's what virtualization solves is another performance optimization technique through which you render only what's visible on your screen. Let's learn by example. All right, I have this demo for you. So this

1:18:34 has two mode. One is virtualization mode, one is non virtualization mode. Right now I am running on nonverirtualization mode. I have a huge list of array which I have rendered in a nonverirtualization mode. It means that I am rendering possible everything. Though if I scroll down and I see like I'm rendering only seven and if I scroll down using this scroll I'll be rendering more elements again and again. I'll make it little smaller so that everything come on the view. Yeah. Now using this scroll I will try to scroll it. I find it really sluggish. You see this you know every time I try to scroll it is really really sluggish. It is really really slow. Now one thing that you can see over here once you go up also it is slow. If I just right click even my right click is also taking some time. I right clicked already. Still I'm not getting now I'm getting inspect. Okay.

1:19:21 And click on inspect. Okay. And then on the inspect bar you come over here inside this div. If I just expand see the number of divs that I have each of the div is nothing but each row right. So even after this many div this div this is the seventh one this is the eighth one which is not there in my visible area but still I have loaded on my DOM it's an extra thing I don't need it I don't need it I don't have to go to 9,999 element because that's not visible guys. So that's one problem. Second problem if I go to the performance tab. This is a performance tab. I'm sure that many of you are not using. If you're not using, you must learn about it. And if you want a video from me how to use performance tab, how to use React DevTools, comment, let me know. I'm going to do that. All right. So, what I'm going to do, I'm going to refresh this and then I'm going to run this recorder. Let's see. I'm

1:20:18 going to refresh this and I'm going to run this recorder. The recorder is running. In the meantime, it refreshes. It bring my UI back stable. I'll stop this. So it will load the trace in a moment and you'll see something. It's loading the trace. It will take some time. It's loading now. It is processing the trace now. Now it gave me some result. Let's analyze this result. What I want you to do, I want you to note down these two things, these two numbers. How much time it took for scripting and how much time it took for rendering. For scripting it is almost 3 seconds 3,275 millisecond. And for rendering 2.3 seconds 2361 millconds total it taken about 8 second for rendering. 8 second for rendering I'm probably rendering 10,000 array elements in different ways right without any virtualization. Now let's close everything. Let's click on the virtual mode. Use the virtual list. This is my virtual list. It is actually showing a

1:21:17 lot of elements but because of my style it is little bit unseen for you. But this is showing. Great part. I can scroll it pretty easily. I can scroll it very easily. Very very easily I can scroll it. There is no sluggishness at all. There are some styling issues that's fine but I can scroll it. So when I inspect this inside this only a few 1 2 3 4 5 6 7 8 10 that's it. Rest of the div not even created on my DOM. That's the power of virtualization. If I come down little bit with the scroll I probably will be adding next 10. If I scroll down a little bit more I'll be adding next 10. I will go 10 by 10 by 10 using the virtualization technique. So that means my initial load is pretty fast. I'm not loading all unnecessary things that are not visible. Here I'm showing probably first six or seven but I'm loading 10 is still okay. I'm loading aggressively three more but previously I was loading all 10,000

1:22:10 together which was a huge kill to my performance. Okay. So that's the first advantage of virtualization. Now next thing I am going to do the same thing with a performance thing. But for that I have to refresh this application. And if I refresh this application the default mode will go to non-verirtual list. Right? So I'll tweak my application little bit. I'll go to virtualization demo. Over here my default mode is non-verirtual. I'll change that to virtual. This one line of code change. Now if I refresh also by default it will be virtual. You see how fast it is. And you see this red also got changed to green. I have disabled the cache and everything. It is how fast you can actually imagine. But let us do the same thing. Can you see scripting? It reduced from 8 seconds to like 2 seconds. It has reduced drastically. It has gone like 1/4 or below just because I have now opted for virtualization. Let's take a

1:22:59 look into the code very quickly. So this is my virtualization demo. I have had a mode based on the link that you click right non-verirtual versus virtual. I basically render two different component. One is the virtual list with all the user data and there is called non-verirtual list. Non-verirtual list is a as usual thing. It's a uli element where I take all these users loop through it using map and show all the information of the user. But for the virtual list I'm using a library called react window react window that helps us in getting virtualization in react. From that I use the component called list which is given by react window to which I pass this data and I pass few configuration value and that's it. It takes care of the virtualization. Right?

1:23:41 So whenever you have to show the long list of data, always ensure that you opt for virtual list, you opt for virtualization, you have seen the performance gain versus performance degradation with the example that I have showed to you. I hope it was helpful to you. All this source code, whatever I have used so far, it's on my GitHub called github.com/tubbascript. You can follow this organization if you find it helpful. Under repositories you will find 15 days of react design patterns and inside this you will find all this code inside day 11 because this is when we are talking about the performance patterns. If you like my work don't forget to start this repository as well. The next technique is about the concurrent rendering using transitions. Okay, React 18 introduced something called concurrency in React to keep the UI responsive. The problem that you usually face when you type into a search box like this that filters among

1:24:35 thousands of elements, 10 thousands element, 100,000 element, your UI freezes, your keystrokes lag, your browser's main thread blocks. That's where React came up with a solution called a hook called use transition. Now we going to see how we can use the hook use transition and where exactly it is useful. You can import the hook use transition from React. The hook use transition give you two things. One is a function called start transition and a state called is pending. The function start transition tells react this particular update is not urgent. Keep the UI responsive while you are doing everything that is defined inside this function. For example, I have this text box. Now this text box has two job. One, if I type something, for example, E9, it has to show E9. And it has another job to pass this E9 to this below list so that this list get filtered and I see the updated result over here. Now if you

1:25:34 think about the user experience, you don't want user to feel lagged when user is typing each of the character over here. It is okay if the processing of this filter list takes certain time because you might have to go to server an API call, you have to process certain algorithm, you have to come back and you have to show the result. So this is okay. You can probably show a loading indicator or something to manage it. But what if you type S and then it's a huge lag before you type E. That's a bad experience. So now among those two operations like one is typing another is filtering which one you think react should prioritize of course the typing into this box. So that means typing into this box can be a faster operation and a secondary operation non-urgent operation would be filtering this particular list.

1:26:28 Now as I had explained what use transition gives us it gives us a function called start transition using which you can define what is that that you can tell react hey react take it you know little bit relaxedly don't don't really panic for this keep the UI responsive while you are doing whatever I have written inside the start transition and when the start transitions function execution is done turn the is pending to false so that I understand there is nothing pending from you in the start transition function. Now with the same example I have two state one is the text another is the query. The text is the input textbox value which you want to keep updated immediately. That's the reason if you see in the handle change whenever somebody typing I'm immediately calling the updated function to update the text.

1:27:20 Fantastic. But filtering the list it depending on something called a query right because if you see this query this is where my heavy list is getting computed okay I'm passing this query now setting this query value what will be the query value based on which I am now filtering my heavy list is inside the start transition function so the start transition function is marking this heavy update as non-urgent updating query triggers expensive filtering plus rendering that and all can be marked as non-urgent for me. I hope this is clear to you. So again, if you want to get much more deeper in concurrency how use transition internally works, I have created a video only for that only for that purpose. You can take a look into that. Again, I provided the link to that video in the description of this video.

1:28:11 It will be helpful, I'm sure. Just like use transition, React gives us one more fantastic hook. It's called use deferred value. Sometime people confuse between use transition and use default value. Let me explain. Both use transition and use default value. Are react hook used for performance optimization by marking certain operation of the updates as low priority. In terms of the demo that we have done for use transition, you know setting the query value that in turn does the filtering we marked as low priority item. Correct? But setting the text on the input box, it is an usual high priority item. Now purpose for use deferred value and use transition is same but how they do it is where it differs both leverage reacts concurrent feature but the primary difference is what exactly they control. The use transition hook what we have seen before controls the state update function. If you remember in the use transition demo

1:29:06 if I have to open it again we were controlling the state transition function of set query using the start transition. Right? Whatever we write inside the start transition function that is kind of deferred that is a low priority item. So here what we control we control the state update function itself. But in case of use deferred if you see the usage of use deferred value here you control the value that result from the state update. Okay there you are controlling the function itself. Here you control the value. So what is happening in this case? Almost similar kind of application. The text which is used in the input element it means that text update on each keystroke must be instant. The deferred text which is computed out of the text and it's a deferred value which means it's a secondary citizen. React is not going to look into it as a high priority. This deferred text is used for filtering my

1:30:02 product. So I could have done the same thing using use transition. In that case inside my start transition I would have had another state called say query or set query. Set query is what I would have marked as a secondary priority thing. But if I want to do it with the value itself I can use something called use deferred value. So use deferred value and use transition sometime people confuses. There's no confusion. Okay. So this is what the differences are and another way where you can optimize your performance. Our performance optimization video won't be complete without talking about this. So, React uses keys to match the old and new elements, right? We know about the virtual DOM. We probably know about the fiber framework and etc. Now, the keys are a very important element in React.

1:30:49 Now, here something is very bad. We have used index as a key. What is bad? Adding or removing item shift indexes. React thinks entries have changed. it break the memorization causes unnecessary DOM recreation. So this is another thing people take lightly. Please don't do it. The right approach, the right way of doing this would be use an ID from your data from your data structure which is unique and use that. So this is stable key. What you should be using when you're iterating through a list in React. Stable keys prevent React from destroying and recreating the nodes.

1:31:24 Helps in better reconciliation. That means it's a faster UI. So this is another thing, another technique that you have to keep in mind. We're almost at the end of the part two. We have spoke about a lot of optimizations but it is not complete without talking about some of the tools. We have seen the usage of a few tools in the part two but let me talk through a few tools that you should explore. You must explore. One is definitely React developer tools. It has a very very strong potential and documentation of React has captured it very well step by step how you should be using it. Please go ahead take a look explore it how to install how to use it.

1:32:00 So React developer tools is one thing. Second thing there is something called React performance tracks. This is something you should be looking into for understanding scheduleuler the cascading updates how components are getting rendered all the aspects of it. Again this documentation is very extensive. Take a look into it. And then there is another tool called React scan which I use very often to see like what part of my React application is unnecessary getting rerender. Catch that guy and try to fix it. So these are some of the tools. I'm sure like it will be very handy for you. As this video and the previous one was very focused on React design patterns and on performances. I didn't cover these tools in depth. But if you think that I should be making a video covering the usage of each of these tool, their right use cases in depth. You know what to do. Post a comment. Let me know if there are more

1:32:52 ask. It's a great motivation for me to make again. And by the way, if you don't want to miss any of those updates, please follow Tapascript because that's where I create awesome content, lot of deep content taking lot of time. I'm sure you're going to love them. So please follow Tapascript. You know that none of my session gets over without the task. In the part one of the performance patterns video, I had given you few task. Let's skip them. I'm skipping them because I've already explained this to you before. Now the new task are remove unnecessary use memo and use call back.

1:33:25 So there is a product card where I have used use call back use memo. You have to gain performance by removing them. You know what to do if you have seen this session. What React provides you from React 19 to automatically memorize your component. You know that. So use that. These are the assignments. Remove unnecessary memorization. Explain why React compiler handle these cases. Identify when memorization is still required and lazy load a country drop-down. Build a form with the fields like name, email, and the country drop down with 250 countries. Assignment.

1:33:58 Move the country selector into a separate lazy loaded component. Show a custom loaded like a spinner. And then measure the initial bundle size with the lazy component versus non- lazy factor of it. And then on the splitting context of the context optimization, let's see how this big context where you have user, theme, cart, local everything together. How can you break them into different context? Maybe user, theme, cart, local, whatever you can think of and then split it. So these are the new three tasks that I have given. You can do it. You can also think of task around virtualization. Take a bigger list. How to virtualize using react window or any other solutions or your own solutions.

1:34:36 You can actually try that. So these are the task. Please complete. Hey folks, how was it? I hope it was helpful to you. I'm super super happy completing part one and part two of performance patterns. I hope you find it helpful. The list of performance techniques, the good practices, the best way of handling performance, whatever you have discussed, please note them down. Take a good look into them and see where you can apply them in your day-to-day life. Before I end, one word of wisdom. Don't try to optimize performance of something which is already working great.

1:35:09 Performance optimization is required only when you found with the feedback whether the feedback is yours, feedback is from your QA team, feedback is from your customer or the possibility where the performance degradation might happen. Then only pick up the technique among all these things that we have learned which is applicable and optimize the performance of your application. I wish all this learning stay with you and you become a champion developer of tomorrow. If you want to catch up more, please catch up React design patterns course which is for free available for free on Tapascript channel. Follow Tapascript for future content, future updates. You won't be disappointed. Take a great care of yourself. Stay tuned.

1:35:51 We'll be coming back again with some great content in the future. Bye-bye.

Questions about this episode

What is discussed in "React Performance Optimization Patterns Course"?

In order: 40:00 GitHub, Tapascript; 50:00 React 19; 1:20:00 GitHub, react window; 1:30:00 Tapascript, React 19, react window.

What is mentioned in this freeCodeCamp.org episode?

6 people, works and ideas are mentioned, including React, React 19, Tapascript, GitHub, react window, Babel. Each one on this page links to its own page with every episode that mentions it.

How long is "React Performance Optimization Patterns Course"?

The episode runs 1 h 36 min; the transcript is about 17,685 words in 118 timestamped sections.

More from freeCodeCamp.org

• All analyzed episodes
• People mentioned on freeCodeCamp.org
• Topics mentioned on freeCodeCamp.org