React re-rendering === Paul: ~Test, test, test a few words.~ Ankita: ~Hello, can you hear me okay? Yes. Okay, perfect.~[00:00:00] Paul: Hi there, and welcome to Pod Rocket, the podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free@logrocket.com today. My name is Paul and joined with us as Ankita Kulkarni. Ankita is a developer, a teacher leader, and conference speaker. ~And you know, before the podcast we were talking about some of the stuff that Ankita, you're into and, you know, self-proclaimed and you can see expert and react in performance accessibility among a variety of other topics. ~And Ankita has spent 10 plus years in tech and has worked at. Big name companies such as I B M, and consulted for a variety of others such as Tim Horton's, burger King, and Popeye's. Ankita has also a variety of courses and has taught over 10,000 students online. That's a lot of students, so welcome to the show in Ankita. Look forward to talking about React and re rendering. Ankita: Yeah. Thank you so much for having me, and I'm really excited to be here. Paul: ~Yeah, I'm hoping to dive into, uh, some details of, you know, reactory and re rendering and performance and optimization since you are, you know, deep into these areas. And specifically, uh, we're gonna get into some of your courses as well, such as engineering management and some of this empire that you've built up of knowledge that is accessible.~ ~Uh, so can we start with you telling us a little bit about yourself and some of the projects that you're currently working on that you feel very passionate about?~ Ankita: ~For sure. Yeah. So yeah,~ my name is Ankita Kulkarni and I've been working in tech for over a decade. ~I've really, I'm,~ I'm really passionate about helping developers level up in their engineering careers, but I'm also at the intersection of frontend [00:01:00] end leadership ~having gone.~ Having become like very senior technical solution architect, ~um,~ and getting really technical in my career and then switching to leadership, but I have a passion for both. So I'm ~sort of~ like at the intersection of the two. ~Uh,~ last year I decided to take my passion for teaching and decided to become a full-time creator educator. Create a bunch of different courses, eBooks, digital products and things like that. And I also have a newsletter that, ~um, ~also helps dev's level level up in their engineering careers, ~um,~ in general that you can check out as well if you want. And on my website. ~Um,~ so yeah, I have a course on next JS and I have a bunch of free content as well that I'm extremely passionate about, ~um,~ to provide to all the listeners. Paul: ~It's, it's great that you give the free content, and I love seeing creators like giving that knowledge base that's accessible online. Um, having more than one spot, that's just youtube.com to access things is, is, is fantastic.~ Ankita: ~Yeah, exactly. And I feel like, I mean, this is what I truly believe in that I think 90% of my content is mostly going to be free. It's going to be all like all that beginner and like intermediate level stuff is going to mostly be free. So I have like an email course on React server components. I have an entry level leadership course that's completely free for people to access because.~ ~They're not sure yet if they won, they like my teaching or not. And second, if that's something that they're passionate about, they wanna like pay money for, right? So I really want all the, those courses, um, all that content to be really accessible. And speaking of YouTube, I also have a YouTube channel that I forgot to mention.~ ~So I'm a fairly new YouTuber where I talk about career development leadership as well.~ Paul: ~Yeah, if, if you search up on Ankita name, you can actually find a variety of, of videos about performance and, you know, accessibility. There's a lot on accessibility that you have a lot in performance. And I mean,~ the topic we're gonna get into today is ~sort of~ related to performance. We're talking about re rendering. ~Um,~ If you're getting into React for the first time, I don't even know ~if,~ if you've might have faced problems with re rendering per se. ~So, ~and, Ankita, could you maybe inform those who might not be familiar? What is re rendering and why [00:02:00] Is it something we're we're talking about? Why is it important? Ankita: For sure. Yeah, ~so I think like when you are, the first thing you,~ when you get introduced to react, you think about ~like,~ okay, how do you create components? And then slowly and steadily, as your app gets bigger and bigger and you start to scale it, you need to think about, okay, how do those components get repainted? On the screen based on, in based like in response to the state that we have, like every re-render in React is caused by a state change. So re rendering in general is basically react to know the difference between what to repaint on the screen and what has changed and the way to react reactors that is using state. So it, we don't have to tell react, hey. Change this specific note in the dom. We basically tell, react, change this specific state and react. That's its job of figuring out what changes and what the difference are, ~what, what the differences are. So,~ Yeah, I can get into a little bit more too. But yeah, that would be like a good intro for ~like~ as you get more and more comfortable with [00:03:00] React, after going through the basics of components and understanding how they all work, you need to understand how React works internally to be able to understand how it reinders and you can take advantage of performance down the line that we'll talk about as well. Paul: I think that's one thing, ~uh,~ that was difficult for me to wrap my head around with React when I first started, ~you know,~ tooling with it, which is that it's literally ~like~ re rendering, like an animation framework. It's a video that's being played 60 plus frames a second. And every single frame. It's doing a bunch of computations, it's doing a bunch of stuff. ~Um,~ and React has a bunch of ways for us to ~sort of~ tackle that. ~Um, I'm not,~ I'm not super familiar with it and I'm excited to get into that and talk about some of these considerations that you might wanna take. Like one of them that I've can search up on Google really quick, like how to make react fast. Use memo. Okay. So use memo with something out there ~that,~ that ~we,~ we can use. And I'm curious to talk about what use Memo does, cuz there's a lot of memes that I've seen about use memo shooting you in the [00:04:00] foot, blowing up your application ~or,~ or something like that. ~Um,~ so ~are, you know, there,~ there must be a variety of hooks and things that you might want to code defensively to tackle re rendering. Could we maybe get into some of. Ankita: For sure. ~Yeah. I,~ I think one thing I would definitely like to, ~like,~ back up a little bit, just to give an example, which can like, ~kind of like~ lay the foundation of all our con like our con conversation entirely. ~Like~ even if you think ~like~ whenever a component reinders, ~like~ one of the things is that all. It also reinders all its descendants, right? And so let's say ~if,~ if you have an example of a parent app component, which is ~kind of like~ the container, ~right?~ And it has a child called as a counter, it's a simple counter application, ~right?~ You can increment the count and you can decrement the count and things like that. And then as a descendant of counter is a magical number that just displays whenever we increment the count in general. ~Right?~ That kind of like you said. You can think of, ~like,~ let's say you're editing something or you can think of a, when you see it, you can, you basically see a timeline, right? Every re-render is essentially a, a [00:05:00] snapshot of what the application UI looks like at that specific given moment. So if you take ~like, Like~ a photo of it and then change something and take a photo of it. That's exactly what React does to ~kind of~ compare the two snapshots and things like that. And as part of that, ~there is, um,~ there are a bunch of different ~like~ hooks such as use memo, use callback, ~uh,~ PR components and things like that too. But that, I would say ~like~ as a first step, you need to really understand that. ~You know,~ whenever you react, Reinder only affects the components that will own the states. ~Um,~ is a common misconception that we have, ~right?~ So for example, ~like we can, we don't need to, um, for example, like if,~ if we do have a descendant, it's also going to re render. ~In,~ in this case counter, right? So ~like~ you can use for example, ~like~ use Memo and pure components and things like that to ~kind of~ avoid some of the, those re rendering in general. But then the point of for React is to figure out ~like~ what needs to change, right? And ~like~ how can we capture that snapshot? So that's something [00:06:00] else doesn't change. ~Um,~ see, I can dig into it a little bit more as well. Paul: So how does use Memo help? Create one of these snapshots per se, to help us re-render less. ~And,~ and ~just,~ just to rere to say we wanna re-render less to ~like~ make the application faster, that's the core. Less re rendering means less work going on ~and~ Ankita: ~Yep,~ yep, for sure. ~So like you can use, for example, like~ whenever it'll allow us, for example, re let's say if you use ~like~ React dot memo, ~right?~ It'll allow us to ignore certain re-render requests. So for example, in that ~like~ counter example that I talked about, let's say we were to add ~like~ a logo in top on top and we are rendering that logo in the counter example itself. We can wrap the logo inside React memo. So that it doesn't get re-render every time when the counter changes because again, ~like~ react, ~uh,~ dot memo will allow us to ~kind of~ memorize the state. So you're like ~kind of~ like cashing it and you're saying that doesn't matter if the counter state changes or not, you shouldn't re-render over and over again essentially. ~So,~ and then there are, [00:07:00] you can also ~like~ make it ~like~ a pure component as well, just so that you know exactly. When, for example, how React works and what, to me memorize and what not to memorize because again, a React com component is considered pure if it renders the same output for the same state and props, ~right?~ So again, that's another way of ~like~ making sure that your component doesn't. Reinder over and over again, right? Because you are, again, wrapping it up in reactor memo or reactor PR components so that again, you're preventing it because it doesn't need it. For example, in our case logo, we don't need to re-render a logo over and over again because it doesn't have any state it doesn't need to, and things like that. Paul: So what a pure component could you say it's ~like,~ An indent component. ~It,~ it, it doesn't, every time you give it the same output out input, it has the same exact output Ankita: ~Exactly. Yeah. So like.~ Paul: ~point in time.~ Ankita: Exactly. So ~like~ if you think of ~like~ a really big application, ~right?~ We would have so many of these PR components where if you [00:08:00] give the input, it'll give you the exact same output. Now in that case, we can just memorize those,~ right?~ Because we don't need to, ~um,~ we don't, ~they,~ they're not gonna change state unless we ~like~ pass a specific dynamic variable state change and things like that. They're not gonna change state. So we can ~like~ wrap it and then, In a big application, you will start to see a huge difference because you're, it has so many pure components in general, and that's how ~like~ React would also ~like~ understand it to ~like~ not touch that specific component if you don't need to. Paul: what's another hook that people might want to use or look at the documentation for besides use Memo to. Effectively cash the state of a c. Ankita: I would say ~like, um,~ another hook would be maybe like use callback as well. So use callback would serve the same purpose as use memo, but it's specifically for functions. So for example, ~um,~ you have. Very, I think we all love dark mode as developers, and let's say we were to [00:09:00] implement like a dark mode functionality on your website, and you can think of it like we all, probably, if you have implemented dark mode before you ha we all probably have this custom hook that we have created that says is dark mode or not, and set the toggle to whatever it might. Now, for example, the function that we create to set the toggle to true or false, depending on the value, whether it's dark mode or not, right? We can easily ~use,~ use callback for that so that we are reducing the time. The number of time a component needs to render and react needs to do as little as possible to draw the. ~Right.~ And again, if you think of it like, ~again, like~ Use callbacks serves the same purpose as Use Memo, but use callback is specifically for functions, whereas use Memo is for arrays and objects and things like that, ~right?~ So for example, ~like if you,~ if you have functions you wanna, you don't want them to read under, over and over again. Same thing ~like~ we talked about, because they're not, [00:10:00] it's not, they're not much of a change, right? Unless the dependencies. Paul: Now what about dangers ~with,~ with using this? So can you maybe give us an example of a function and how using used callback might be dangerous or a bad choice to use? Because I know it can be, I'm not really sure how to outline an example. ~Like~ could you blow up the memory? Could you blow up the ccp? The CPU of the browser? I'm not really sure. Ankita: Yeah, I think like you might have noticed infinite reinders and your application kind of like your browser. No, just crashes cuz you're not sure. Cuz you're totally using a dependencies that keeps changing and it, there's an infinite re-render at that point. And in that case you need to be~ like~ really careful. ~Right. So I would say like,~ I would like to back up a little bit, ~right?~ When you think of performance in general, what you need to think about is. When if you have~ like~ a small application, you don't necessarily need to think too much about performance, right? Because reactor is gonna do [00:11:00] its job, but then when the application gets really big, it's massive. We have so many different components. That's when you ~kind of~ have to pick and choose in terms of which components you wanna. Monitor, ~right?~ Which components you might wanna change and tweak and add, use callback and use memo and things like that. Or if there's a component, for example, a logo, that's not gonna change at all, ~right?~ Your logo is gonna stay the same. Then you can~ like~ add, ~like~ make it a pure component ~or,~ or memorize it and things like that,~ right?~ But I don't want, ~uh,~ to complicate it by saying, Add a use callback and use memo in every single component and over architect it because that's not the point of performance. A performance with performance, ~like~ you need to think about, ~like~ when it starts, you start to see that the application is growing. Let's say you're using forms and it's going, it's creating this, these, a lot of redders in your, you're noticing, ~uh,~ the speed is getting a little slow. That's when you start digging into. Use callback and use memo and things like that just to then understand [00:12:00] and ~you know,~ what you're getting into. Because otherwise react is going to do a good job out of the box to, ~you know,~ not, ~uh,~ handle it mainly for you. ~Right. Um,~ and one thing, another thing I would also add is in terms of performance, ~um,~ You wanna make sure that you're also testing in production too, because in development mode you're going to see that the app is slow and things like that. But in production test on an actual, ~like~ real device, on a slower network and see how your app performs. So ~to~ to see the impact of performance in general. Paul: Yeah, and making calls across actual network boundaries is totally different than making a call to your local database, ~um,~ profoundly different. ~Like~ they add up, they stack up exponentially, ~so,~ Ankita: Exactly. ~Yeah.~ And then you have, we have so many other tools such as ~like~ React, profiler from the reactive tools. So if you install reactive tools inside Chrome or Firefox, right, you can use the profiler just to capture that snapshot to understand and monitor if that specific component is changing, ~right?~ So for example, you asked me about, You asked me about [00:13:00] use callback, ~right? When,~ when would we see start to become a problem? I would say that install reactive tools, go to profiler. There are two options. One is ~like~ make sure that you are in production mode, right? And you're testing things on maybe lower and hardware and things like that. But there are two properties inside React profiler to make sure that it highlights is a checkbox there you need to, can highlight the re-render. So anytime the application, any, anytime the component re render is gonna highlight it for you. Then you're Paul: you can visually see. Ankita: Exactly ~and like,~ and ~we have,~ we have learned that a lot of educators right now are. Teaching things visually because we as, I guess ~like~ just in general as developers, we love things. We love things, ~uh,~ we love to take, see things visually. And that's ~like~ a really good example to see that visually, see which components we are under. And you're like, why is this prec? Pure component re rendering or ~like~ why is it lo logo re rendering, just as an example, right? There are other pure components too. ~Um,~ and you can see that and ~kind of~ then dig into it and fix it. But no, being [00:14:00] aware of these hooks and what they do and when to use them is like key to learning more about performance. Paul: ~And if you want to get more into debugging and sort of like seeing what's going on in the front end, besides, I'd love to learn more about, uh, react Profiler. Um,~ Ankita: ~you got cut off? Cut out there.~ Paul: ~no worries. Can you hear me again now?~ Ankita: ~Yes. I can hear~ Paul: ~Okay, awesome. Well, I was just going to add.~ In addition to, ~uh,~ the React profiler that you've been suggesting, I'd love to dig in a little bit more into that. But for any front end developers or full stack developers, honestly out there who are looking to solve some issues that they might have in their application or really bring their application to the next level, I'd like to remind our listeners that the podcast is brought to you by Log Rocket. ~Uh,~ log Rocket offers session replay so you can see what your users are doing. Issue track. And product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve conversion and adoption, and spend just more of your time building a better product and less time debugging. And if you were going to step into using React profiler, ~like~ one thing that excites me about that and when you're like, it's visual, a lot of people are ~like~ doing visual experiences.[00:15:00] ~Um,~ I read this interesting article about how we as humans just process things visually faster. ~Like~ we can read text and it's effective and it's simple. But ~man,~ if you can paint a picture, it speaks a thousand words. And ~that's,~ that's is so corny. But ~man, it like,~ it's true. And so ~with,~ with this tool you're talking about, is it ~sort of like~ flashing if you got a re-render problem, what I see like flashing on the screen of it, highlighting and going over and over ~like~ a siren almost. Ankita: ~Yeah. Yeah,~ exactly. ~And I, and I think~ I would love to go back to the point you made very early in the, in, when we started off this conversation was, ~um,~ the. ~Kind of like a~ timeline and animation and you ~kind of~ see ~like~ a video. That's exactly what a profiler does, right? ~Like~ it'll flash for you whatever a rear render occurs, ~right?~ So you know which component, ~um,~ is rear rendering. So it's gonna give you that flash I'd like, so you can successfully avoid re rendering in those cases. And it's also gonna take, you can record it, right? ~Like,~ for example, do a bunch of things, click around on the screen, you can record it, and as you record it, it'll [00:16:00] take snapshots for you, ~kind of~ like you said about recording a video every Paul: Yeah, ~like, uh,~ the session re. Ankita: Yeah, exactly. And ~um,~ I'm not sure, ~like for example, like I'm not sure~ if you've done snapshot testing before. That's also ~like~ another way of thinking of this too, where whenever you're testing a component, you basically pass it a bunch of state and whatever, however you wanna test the component and you take a snapshot, ~right?~ So you have exactly the output of what the component will look like and its entire dom and things like that. Now if you were to make changes again in the state and the component is re-entering all the time, a snapshot is going to fail because it's no longer the snapshot that we were testing with. Right? Which is another good way of, I just wanna call our testing here. Another good way of testing out if your component is ~kind of like~ re rendering all the time so that it's more automated. Right? And you're writing tests for it as. Paul: ~Uh,~ speaking of testing and ~sort of like~ doing analysis of your application,~ I mean,~ everybody's familiar with Lighthouse and the [00:17:00] great utility it provides us as web developers, but it doesn't do everything. And I'm curious, like specifically from your perspective and Keita, what does Lighthouse do and what doesn't it do with respect to like performance and how well your website is organized? Ankita: For sure. ~Yeah.~ So ~like~ Lighthouse would is a great, ~is~ is a great tool, ~right?~ It would give you these different metrics in terms of how accessible your app is or how performant your app is and will give you ~kind like~ a score for it, ~right?~ But it's ~like~ a really basic. It is a starter thing to do, right? ~Like,~ yes, I wanna run the lighthouse test just to make sure what the score is ~like,~ and it'll sometimes definitely give you suggestions to improve it, ~right?~ And ~like, um,~ Google B Dev Insights also helps with that too. But what it wouldn't do is wouldn't tell you the entire picture for why it is happening, right? We, because what happens is Lighthouse perform evaluates performance. A single page load, which might not completely reflect the [00:18:00] user's journey, user interactions, subsequent page loads, ~um,~ and things like that, which all would contribute to overall performance of application. Lighthouse necessarily won't do that, so I don't, I think it's a good start for li to use Lighthouse, but I don't think it should represent performance in its entirety because performance is way more than that. So I would say ~like,~ test on, you know, Hardware that you wouldn't, they're not ~like~ really fast iPhone apps, right? Or ~like~ iPhones or ~like~ test on different devices, test on a slower network and things like that. ~Um,~ and I think that would show you why performance is really important, because if you think about it, these users, ~like~ we, we are talking about performance because we want apps to be fast because our users are not going to care about what libraries or frameworks are using in the background. All they're gonna care about is I want this app to be really fast. I want my data that I need. And that's why I feel ~like~ Lighthouse is a great start, but testing it and making sure [00:19:00] that. The user experience is intact is another thing which we need to do On top of that. Paul: ~Like a,~ would you call that an end-to-end test or if you were to ~like~ take the phone and. Go load it up on a slow network Ankita: Yeah, for sure. I think so. I would say ~like~ end-to-end test integration, testing and things ~like~ that too. ~Um, I mean,~ you can, there's a huge debate about end-to-end test versus integration test and things ~like~ that, which I don't wanna get into right now, but ~like,~ yeah. Yeah. But just ~like,~ I think that it's, Something that it's important, right? ~Like~ how does our user see the app in their hands and on different devices because we might be having ~like~ the fastest network, ~um,~ and the fastest device possible, but that's not, doesn't represent all users when it comes to performance. Paul: The tricky thing is too, if you take a device and then you go out in the field and you find that your console on your application is slow, it's like, okay, ~I,~ I found this out. I can see in the profile, or maybe something's re rendering. Maybe I can see in the network something's going on, but ~like,~ Actually [00:20:00] digging down and figuring out the different bits and pieces, the nuts and bolts about why something is slow ~is,~ is really complex. And there's a lot, like you said, it's performance. It's not just one little piece. ~It's,~ it's a lot of, ~it's,~ it's a whole field. ~I mean,~ it's a whole field. Just for this one framework we're talking about react, ~you know,~ love it or hate it. ~And, um, I know that you. Put in a lot of work, like we said at the beginning of the podcast, like over 90%, you're, you're hoping of like free content out there, a great knowledge base you're building, um, in addition to some other like courses that you've put a lot of time into procuring for folks out there.~ So out of the courses that you've put out, which ones do you think most tightly correlate with what we're talking about right now? If we want to get into~ like~ performance and the details of React and these hooks we're talking. Ankita: ~For sure. Yeah. I would say like I worked on, um,~ one is a free course, another one is a paid course that I would talk about, but I would say ~like~ the free course, ~like~ React server components are really, ~uh,~ A hot topic right now because with next year's 13, ~um,~ react server components are, have been introduced, and how we render components on the server are a really big deal right now because then we don't have to, ~um,~ render things on the client as anymore. We can just render it on the server.[00:21:00] ~So my, one of my,~ I have a. Course on just react server components and talking to you and discussing about ~like, um,~ how react server components work, how in some of the advanced best practices as well in terms of that, which would give you a good starter. And again, it's on the basis of next day as 13, which is still experimental right now, but hopefully soon it's not going to be anymore, which is. ~Um,~ which, and the other course is that next JS is the course that ~I have,~ I have worked on, ~uh,~ that will teach you, we build ~like~ two really cool apps. One is like a coffee store app that you could discover coffee stores. And second is ~like~ a Netflix, which is ~like,~ gives you a real world example of what it takes to build a production ready app in next year's. Paul: I think one thing that's great about next JS 13 is it's almost like people are gonna be forced to use server components cuz it's ~like~ now the default. ~Like~ we've always been able to use them. Ankita: Yeah. Paul: ~now,~ but now it's the default if you use the, ~uh,~ app directory, right? And, ~um,~ you ~kind of~ get thrown right into it if you [00:22:00] haven't messed around with ~like~ the whole client versus server paradigm and like making that choice. Ankita: Yeah. Yeah, exactly. ~And I think that in,~ in fact, ~like~ I have a demo and that's literally what I do to te introduce people to react server component. Just ~like~ flash, ~like~ this is a server component and by default, right? Or this is a client component and ~like~ you're going to render things in the. In the client. For example, if you add a used client director, ~uh,~ on top ~right,~ but by default everything is a server component. And again, like you, if you install reactive tools, you can ~kind of ~see also like the bundle and see which components get included in the bundle versus not to tell you. Which components are on the server versus on the client, which is another cool thing about, ~uh,~ no, ~you know,~ performance in general, ~like~ you have a smaller bundle, ~right?~ Which again, helps when you are showing that to the users and things like that. Paul: ~If people were to walk away from this podcast and they wanted to sort of make it their mission over the. Two to three months to sort of improve their knowledge on performance and their hygiene. Um, you know, we talked about a few general topics today. We talked about hooks, we talked about, um, going out and finding some more like knowledge out online about, uh, how, how these frameworks work and how they re-render.~ ~We talked about Lighthouse and maybe how it doesn't do quite everything. It's a good start, but there's some other things to consider.~ What would you offer people who wanna set out on this journey in terms of tools to look at, in terms of [00:23:00] resources to look at and, ~uh,~ just areas that you find people might overlook in the 10,000 plus students, ~you know, you've,~ you've helped go through on their journey as developers? Ankita: ~Yeah, for sure. I would say that the biggest thing that, oh,~ I've seen a lot of developers overlook. An understanding of how react reinders, and I think that's the big gist of it. Like I wish I could provide more and be like, here this is, these are the all the advanced best practices that you can work on to. Improve your performance over the next few months, but I think we really need to understand how React Reinders, how to use those hooks and to leverage to the best of your ability, right? This way ~you,~ you are, you have a set of really powerful tools at hand and you can understand this is something that you should. ~Um,~ be using or not because having that knowledge is ~like~ really powerful in general. But the second thing I would also say is really dig into react profiler and get a really visual [00:24:00] understanding because when you see things, you'll suddenly have build that empathy for performance in general. ~Right. Um,~ and lastly, I would say, When you start working with React in general or ~like~ if you are exposed to a new code base, don't think of performance once it becomes a bottleneck, right? Don't think of it as an afterthought. Think of it ~like~ beforehand and start eta, ~like~ building these practices from the get-go. You don't have to over-optimize it by making every component a pure component or try to extract everything out. All the state out to the container or things like that. But what you need to do is really, ~uh,~ have a good understanding of how these ~all, like,~ all this works so that you can, you don't treat it like an afterthought. And once it becomes a bottleneck, because what I've seen is that when application gets massive, and I've been in those code bases where we have so many different react components and sudden. One, this one page. It's really slow and we figured, [00:25:00] we look at the backend and the APIs are not slow. It's actually the front end bundle that's really slow and ~we~ we, and to figure out why, which component re renders and why it is then infinite render and things like that was like, Was really challenging. So what we did at the time was really, again, trigger use, react, profiler to figure out the component that was the culprit in that case, really, which component was re-entering, and then investigated its dependencies in every hook to see which one. Should change, which one isn't changing. So ~like~ really auditing that will really help you build a solid foundation as well. But again, this goes back to, I think it's like a sort~ like~ we are in a loop, right? It goes back to yes you, before we get there, really we need to understand why it's happening, how react works, why it re renders so that we can build that empathy for performance and really, ~um,~ know what we are doing when we see React profiler and things like. Paul: ~And,~ and love it or [00:26:00] hate love or hate react. Like their docs are well known to be like a very well put together, set of, ~um,~ tools for you to go over ~and,~ and learn about react and how it reinders. ~Um, are,~ are there any other resources that you might suggest that. ~You know,~ I know for example, the JavaScript event loop, everybody knows that one talk that's ~like~ 26 minutes on YouTube, ~uh, that~ that shows how the event loop works and everybody's ~like,~ oh yeah, that's the one talk you have, you gotta go search up. I wonder if you have any other, ~uh,~ resources that you found very effective for learning these fundamentals. Ankita: ~I know that for example, like.~ The one resource that I love to look at, and I know this was, I think in 2018 or 2019, josh Comeau has a talk on react animations and how saving the web 15 milliseconds at a time, that talk is really good. That will give you a good understanding of performance. ~Um,~ and Paul: title. Ankita: yeah, which is amazing because he talks about how animations impact, ~uh,~ performance and how we can. ~You know,~ change simple things like even accord. To use c s s [00:27:00] versus react to tweak performance, which is like these little details. I think that talk is like really good for performance in general, but I also, I would say like we talked about use memo, use callback, and how we as you developers need to handle it all and under have, build a solid under ~have to~ have to build a solid understanding in general. Right. But the React teams right now is, Working on it so that we don't have to do that. And they are experimenting and I believe testing right now so that it all part becomes part of react. And we don't have to think about it, ~uh,~ as much as we do right now because we do need to think about, right, like where we, where are we declaring state, how do we. How does that state impact all the descendants components, which components to make pure components are not, or which when to ~use,~ use callback, use memo and it all this. There's a lot of confusion in the React community for it. So the React team [00:28:00] is working on that. I know the testing, so that might happen. It might not, who knows? But that is something to watch out for as well, ~um,~ just to see what happens there. That means we don't have. We still need to know about it, but we don't have to think about it as much as we do right now. Paul: And is there anything that you're planning in the future for your courses or any of the content that you're putting out? ~That. Are you gonna keep up to help us keep up to date with what they're doing with this testing?~ Ankita: ~Yeah, yeah, for sure. So like in, in terms of in like React or just in general~ Paul: ~J. Both of them both.~ Ankita: ~Yeah. Yeah. So, In terms of like,~ I am really passionate about performance, so I am planning on working a course on React performance. ~Um,~ but I think the best way to check to keep an eye on it is just ~check,~ check out my newsletter where I do share things, snippets, visually, ~um,~ and teach developers in general, ~um,~ to things like use call back, use memo and things like that. And just like in a very simple. Less than five minutes, ~uh,~ a day kind of thing. So ~like,~ definitely check that out. But then the other course that I, I'm working on right now is to help developers level up in their engineering careers and become leaders if they. If they are [00:29:00] interested in doing or just like openly talking about that topic too, because again, there was not a clear path for me when I was transitioning and I ~kind of~ dabbled into it and figured out by finding the right mentors and co hiring the right coaches and things like that. But that is something that I'm passionate about as well. And I have a course coming out on helping developers transition into leadership. ~Um, I think it's~ Paul: ~Sort of like soft skill.~ Ankita: ~Yeah, so like it's basically it will teach you how to become a manager or a leader in general, engineering leader. So that will tell you all, everything that you need to know, like how do you group performance reviews, how do you give feedback?~ ~How do you grow people? Or how do you still be technical as you grow into leadership? So things like that, because again, I'm at the intersection of front and end leadership, so I'm passionate about both and something that, how do you lead a team and make sure that. Practices and the technical excellence in the team is great.~ ~So it, that course covers it all.~ Paul: What was the address? One more time? The web address Ankita: Yeah, it was It's developer to leader.com. Paul: developer to leader.com. Ankita: ~Yeah. Yeah.~ Paul: ~And, um, if people wanted to follow you and Keita, do you have a Twitter handle, uh, that people.~ Ankita: ~Yeah. Yeah. So like~ my Twitter handles Ku k and nine, ~um, that they can follow me,~ but also, ~like,~ the best way to know what I'm up to is ~also like~ my newsletter. ~Um,~ I have created a special link just for, ~uh,~ pod Rocket. So ~like,~ you can just go to K Kearney and keita.com/pod Rocket and ~like~ whatever links we talked about, I have ~like, like~ added all in there so ~that users,~ the listeners can just go there and it's easy for them as. Paul: ~Beautiful. So that was AnkitaKulkarni.com.~ Ankita: ~it's cool.com/pod rocket. Yeah,~ Paul: awesome. And we can provide that link in the show notes as well for people to click and copy and paste. Ankita: ~for sure. Yeah.~ Paul: Well, thank you for your time and Ankita Kulkarni talking about [00:30:00] performance and some of the utilities tools and other things available just in Native React to help us, you know, tackle that problem. ~Um, And we hope to have you again on soon, sometime in the future, and maybe we can dig deeper into actually how re rendering happens. And I know we were kind of dancing around the subject of like, oh, it, it's complicated. So maybe we can get into the weeds sometime in the future about actually how the machine works underneath.~ Ankita: ~Yeah, yeah, for sure. Yeah. Um, yeah.~ Thanks so much for having me. It was lovely being here.