Noel:
Hello, and welcome to PodRocket. I'm Noel. Today we're talking with Shruti Kapoor, who is a lead member of technical staff at Slack. She recently spoke at React in the Park this year, about React 18, which we'll kind of be covering this episode, and other stuff too as we explore a little bit. But yeah, welcome to the show, Shruti. How's it going?

 Shruti Kapoor:
Thank you so much, Noel, for having me on the show. It's been going great. It's a Monday here. Short week here, so getting started, excited about the upcoming weekend already.

Noel:
Yeah. Yeah. We have a short week too. So, I'm feeling that four-day week energy and looking forward to the weekend. Awesome. So yeah, let's just get into it. Tell us about your background. You recently moved to Slack from PayPal, right?

 Shruti Kapoor:
Yeah.

Noel:
Yeah. How has that progression gone? How has your career changed over the years? And how have you found yourself focusing on front end stuff?

 Shruti Kapoor:
Yeah. I moved to Slack almost a month ago so I feel like I'm still understanding what I'm supposed to do at Slack. At PayPal, I worked there for four years. I was working on the front end side of things there as well. Heavily involved with React and [inaudible], some Redux in the front in my initial years. I have been working in the front end space for almost eight years now. And I started off as a web developer working on WordPress as well, so like super, super front end.

 Shruti Kapoor:
I guess how I got involved was, once I started working professionally in React, one of the things that I kept thinking was React and Redux are the same thing, because they were so confusing and so tightly coupled. I think even now people have that problem when they're starting with it. So just working through that and understanding where to draw the differences and helping other people figure out the same things as well is kind of where I found my passion of helping people understand front end technologies. Because there's so much that goes on and pretty much all of us are stuck on the same questions when we begin.

Noel:
Yeah. Gotcha. Did you have any background in, I don't know, education or just bringing people into a knowledge space at all before this? Or was this kind of a novel thing for you as you were getting into development?

 Shruti Kapoor:
It was kind of very new to me. I used to be a tutor to little kids when I was, I don't know, like 16 or something. So I used to teach grade seconders. But teaching developers and all that, that was kind of a novel thing. I think I just enjoyed helping people and making them understand a concept that I struggled with at some point as well. I'm kind of giving them the same story that I used to understand the topic myself. So I was able to relate to people better and I was able to understand their struggles as well. So that got me passionate about helping them understand front end topics even more.

Noel:
Nice, nice. Very cool. Awesome. Well, yeah, I'm excited to kind of get into React 18 stuff here. Again, some listeners may know a lot, some may not have new releases on the radar and they're too far down in the weeds and maybe this'll be like a, there's cool stuff on the horizon kind of moment for them. But before we get in, I've got in my notes that you're a big fan of dev jokes. So I'm going to put you on the spot. You got any good zingers for us quick before we get in the weeds here?

 Shruti Kapoor:
Ooh. Okay. React. Okay, so let's talk about a React joke. What did the proud React parent say to its children?

Noel:
I don't know. I don't know. What did they say?

 Shruti Kapoor:
I got to give you props.

Noel:
Oh yeah, nice. So bad. So good. So bad and so good. I love it. Nice. Excellent. Excellent. Okay, cool. Now that the tone is set, let's get into it here. Yeah, so React 18 released in March, right? That's what I got. Yeah, March.

 Shruti Kapoor:
Yeah.

Noel:
Can you give us some of the ... like what's the coolest new stuff? What's exciting for devs? What are you excited about?

 Shruti Kapoor:
Yeah. So React 18 was officially released in March, 2022, but it's been out in alpha and beta phase for a while. So the one interesting thing that they did for the very first time with React 18 is they founded this React 18 working group, which basically is a group of community people, educators, library maintainers, who are all understanding what React 18 is going to be about and helping educate the community as well. So something like what I'm doing right now. So basically the releases have been already in discussion with the working group members. So it's been public for a while, but officially released in March 2022.

 Shruti Kapoor:
I think the biggest feature that I would say that React 18 focuses on is actually making sure that it removes janky user experiences. So the janky UI experience that other ... like in previously, you would have to think about and code around it, those have been now been automatically taken care of. We'll talk about some examples when we talk about automatic patching and concurrent rendering, but the main idea is that React 18 focuses a lot of its efforts on ensuring that UI is performing, and a lot of the things that you had to think about previously, about like making sure that your user input is at higher priority or that when you're writing something, that goes in first and the data that's rendering in the background, that can be deferred, all of that has now being taken care of in React 18.

 Shruti Kapoor:
So the big theme is concurrent rendering and we'll talk about what that is, or like concurrency and some of the features that come around with it. But that's the main goal, to make UI more performing so that most of the updates are UI centric updates.

Noel:
Got it. Got it. So when you say the big theme being user experience, we're talking about the end user of the web app, not necessarily mean the developers?

 Shruti Kapoor:
Correct.

Noel:
But it sounds like they're kind of brought along as well in that they don't have to worry about these things that may end up impacting their users at the end of the day as well?

 Shruti Kapoor:
Exactly. Yeah.

Noel:
Cool. Cool. Very cool. Yeah. So again, we can kind of jump in on wherever you think makes the most sense. Is maybe just talking about concurrency, is that kind of a good place to start?

 Shruti Kapoor:
Yeah, let's do that. So to think of concurrency, think of ... basically the way it sounds is like React is actually doing multiple things in the background. And to kind of make you understand concurrency, there's an example in the working group discussions that one of the core members gave, which I'll give here. So let's say that you have to make a call with two people, Alice and Bob. So you're calling with Alice, but let's say that the call with Alice, let's say maybe it's like a customer service call. So you say something, they put you on a hold, and then you're just waiting for a long time. And then once you're done calling Alice, you end the call and then you can call Bob. So that's how you do a synchronous call.

 Shruti Kapoor:
But in the model of concurrency, what you can do is, let's say you call Alice and you're put on a hold, you can actually put that call aside and then call Bob at the same time. And then once you're done with Bob, you come back to Alice and finish your call there. So in the time that you were previously spending waiting and talking to Alice or being on hold, you don't have to spend that time anymore. In that time, you can actually talk to Bob. So basically you can do two things at the same time. So in React's perspective, it basically means that if you set anything as an urgent update, or if you set something as a higher priority, that takes precedence over a lower priority task. So React is able to do multiple things at the same time while still giving a good user experience to the end user.

 Shruti Kapoor:
So that's concurrency. And concurrency is actually a foundational feature. So in the front, as a user or as a developer, you don't have to think about it. You don't have to write anything that needs to be concurrent. It just gets taken care of in the background. So React 18 basically introduces concurrent rendering as a foundational feature. I guess an important thing that concurrent React introduces is a few different concurrent features, such as automatic patching, the startTransition. We can talk about them, but those are the features that power concurrent rendering for a developer. So you wouldn't be using a concurrent feature. Like you wouldn't be using concurrent rendering assets, but you would be using features that power concurrent rendering.

Noel:
Got it. Got it. So what was the state of concurrency in the rendering engine before, like in previous versions?

 Shruti Kapoor:
Yeah. Great question actually. So previously, concurrency was kind of an experimental feature, but it was enabled by using something called concurrent mode. And the difference between concurrent mode and what we have in React 18 is that concurrent mode was actually an all or nothing thing. So once you opt into concurrent mode, your entire app is concurrent. But with React 18, what you can do is you opt for a feature that enables concurrency, so only that part of that feature or that code is concurrent. Your rest of the app is still whatever it was before. So it's no longer like an all or nothing thing. You can choose and plug in wherever you want concurrency.

Noel:
Got it. Got it. Cool. Very cool. Maybe to help us kind of frame a little bit more, can you give me a good example of an app that may stand ... or I don't know, just a functionality that may stand to benefit from having concurrent rendering?

 Shruti Kapoor:
Yeah. So let's talk about, let's say ... I think one of the features that we can talk about is startTransition, which is a feature powered by concurrent rendering. So let's think of an example where you are searching in Google. When you go to google.com, you have a search box and you are writing something like, let's say Reactathon. So as you start typing, you are also seeing ... you're seeing two types of feedback. There's one where you're actually writing a character in, so your cursor is updating, your cursor is moving, your character is coming through. And there is a second type of feedback where when you are typing Reactathon, as you're typing, your search query gets updated, and the dropdown box shows up. So there's two types of feedback happening, right?

 Shruti Kapoor:
So if you think about it, previously, what you'd have to do is, let's say you have a slower connection, you would kind of have to debounce your search so that you can kind of show the input query first, because that is a more important user feedback. So now with the help of concurrent rendering, and by using startTransition, the feature, what you can do is you can tell React that, I want the input to be a higher priority, and I want the search query, like when I type and search that, that to be a lower priority. So with the help of concurrent rendering, what React can do is prioritize anytime a user input comes in. And then if you are searching before, like let's say you were searching for RE, when you type REA, Reactathon, or React, that gets, RE search query gets discarded. So it gets thrown away. So it never actually renders. So that's concurrent rendering in a nutshell, and this kind of feature would be super helpful with new APIs that React 18 is powering.

Noel:
That's nice. So I guess in my head, the old school way of doing this, like you said, I'd have a watcher or something, something watching input. And as I type, I'd then be like calling a function, which debounces, and then when the response comes back from the server or upstream or whatever, I'm updating my list of auto completed suggestions in the search box. Is the goal with concurrency, so I don't have to think about this anymore and like debounce that function and do all that work? Or what's the end goal of having this API?

 Shruti Kapoor:
Yeah, basically. Yeah. So that's the goal, that you don't have to think manually or write code manually to debounce it. And this kind of thing is even more prevalent when you have a slower connection or when you have a slower computer, because you're not able to prioritize those two, like React wasn't able to render those two features as fast. So with the help of these concurrent features, now you don't have to think about where to add thought to or where to add the debouncing. And so React can automatically take care of that for you.

 Shruti Kapoor:
And one of the cool things is, with debouncing, you set a timer or you set a delay and it definitely gets ... it's a definite delay. So after that certain time, it will get debounced. But with React's feature, concurrent features, it's actually more intelligent than that. So if you have a slower computer, it will get debounced, but if you don't have a slower computer and it's fast enough, then it won't get debounced, like it won't get throttled. So that's interesting.

Noel:
Got it. Got it. So it's the intelligence of React that we're talking about there? Is that just on the rendering side? So say there's again, API calls happening behind the hood. This is just the DOM ... or we're getting information that we're then instructing the DOM to update. We're just saying that React is smart enough to know what work it needs to be doing to update the DOM efficiently. Is that accurate?

 Shruti Kapoor:
Yeah. Yeah. So this work is basically on rendering the DOM and updating the DOM. I think what you're alluding to is calling an API and how to be smart about it.

Noel:
Right, right, right. Yeah.

 Shruti Kapoor:
I think that feature is actually powered by some libraries, like Next.js along with Suspense. So I think that is work in progress and it'll probably come up in the future, but right now this is ... what I'm talking about is actually updating the DOM and rendering on the DOM.

Noel:
Yeah. Yeah. I was just kind of making sure and clarifying for listeners that we're talking about all else being like done and handled and happening efficiently, just like we're telling React to do things, making sure that it can do it quickly, and we're not slowing down the device based on how we're telling the front end to render itself.

 Shruti Kapoor:
Yeah.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show.

Noel:
Yeah. I think you mentioned automatic batching and transitions. Is there one of those we should dig into next?

 Shruti Kapoor:
Yeah. So let's talk about transitions actually, because we were talking about that Google input field, right? So going back to the Google input field. So we were talking about there's two types of feedbacks. One is more important. One is lower priority. So how do we tell React which is more important? So we can tell React with this new API, which is called Transitions. And basically the way you can access this API is either through the startTransition function itself, or you can use the useTransition hook, which is a new hook as well.

 Shruti Kapoor:
So the idea is that transition is actually a lower priority update. So you tell React what you want to mark as a lower priority. So let's say in this case where we were searching, we want to mark the inputting the user field as a higher priority, but we want to mark searching for something as a lower priority. So whatever is our lower priority, we wrap that within a transition. And so you can use startTransition and it's like a call back function. It's like a function. So basically you write startTransition and you put whatever search query inside your startTransition function, and that tells React to mark it as lower party. So I think it's just one line of code and that takes care of basically deprioritizing that update.

Noel:
Got it, got it. So the hook essentially makes it so that update can happen, I don't know, later in the event loop. Is that kind of a way to think about it, like just kind of pushes it down the line? Is there any other work that it's doing for us?

 Shruti Kapoor:
So basically what it's doing is it's telling React ... it's loading the priority of rendering that for React. So let's say that you have two inputs. A is a higher priority input, B is a lower priority input. So A would be like typing in the user field and B would be searching here. So let's say that A comes in and we are already firing B, we're already in progress, we're already rendering B. So as soon as A comes in, React discards B or pauses B and then inputs A in, so shows A in, the higher priority in. And let's say we've got more of A's coming in, so that still gets prioritized. And once we have done rendering A, then we go back to rendering B, if we need to.

 Shruti Kapoor:
Let's say during this time, there was another input that came in for B, the lower priority input. Anything that was previously being done for B would get discarded. So basically you would always have the freshest state of any of those two functions, but the higher priority function or the higher priority update, which would be A, in this case, which is us typing in the query, would get executed first.

Noel:
Got it, got it. And so if I'm a dev looking to use these hooks, does one usually kind of work their way backwards into finding themselves using them? Like they're testing things and they're like, oh, well, I need to prioritize A over B in this case, or vice versa, and then they end up using these hooks? Or is this something that you devs need to be kind of proactively thinking about as they're writing interactive user interfaces?

 Shruti Kapoor:
I think the one way that I've been thinking about it is like, when I'm noticing that something is slow or something that I'm using a lot of rendering behind the scenes, or it's a heavy task, then I'm thinking of, is there a concurrent feature that I can use? So for example, the search query was one. Another one is, let's say you have a big table and you are putting in a lot of data. You could think of ... let's think of this case where you would think that React needs to do a lot of work in the background. So for me, I'm thinking, is there a React concurrent feature that I can use here? And that's how I'm going about using these React 18 features. So basically you already have an app going. Now think of where in your app do you think there could be a large rendering task happening and see if you could use a concurrent feature there.

Noel:
Got it. Got it. And this is the ... we're talking about the transition hooks right now, right? Or the ... yeah. I guess they're implemented as hooks, but however one wanted to use them, you could.

 Shruti Kapoor:
Mm-hmm.

Noel:
Are there more than one? Like how does that API look? Are there multiple hooks you could use?

 Shruti Kapoor:
Yeah. There's a few different hooks that React has released. I think the official docs has a few different ... has a whole documentation of how to use them. But a few different ones. Another one that comes to my mind is useDeferredValue, which kind of does the same thing of improving the rendering behavior. But where useTransition is kind of thought for UI changes, like you want to move from one screen to another, or you have a few different UI changes you're thinking of, useDeferredValue is more for letting React know that this is the data I want to render.

 Shruti Kapoor:
So for example, let's say that you have a big table, like we were talking about this, and you want the table data updates. You're probably fetching it or you're calculating it or whatever. So you want to tell React that, I want you to defer the loading of this table because there is a higher priority update that I want to show. Maybe you have an avatar you're clicking, for example, in the case of Jira. In that case, you could use a hook called useDeferredValue, and basically it would tell React to load your table with this data, which is actually deferred, because there's a higher priority update on the page, which would be clicking between avatars or clicking tabs or clicking a different link. So you're deferring the loading of that page, of that component.

Noel:
Nice. Awesome. Awesome. I guess, if you're a dev and you know you have these kinds of performance problems, and I don't know, some complex UI where you're ... have multiple filters and they're affecting each other ... to continue your table example, maybe there's a table and there's multiple filters or profiles that might control the data that's being rendered. What would the easiest way for a dev to go in and figure out how they can use some of these tools to help them improve the user experience?

 Shruti Kapoor:
Yeah. So I think what I've been doing is I look at my code and see, am I changing? Am I trying to improve the performance of a screen or screen state transition? So for example, I'm clicking between two different tabs, I need to show one tab versus the second tab, versus the third tab. Or if I'm doing a rerender of that component. So basically what I'm trying to do is finding out where are my performance blocks and which feature could be better, or what I'm trying to do there. So if it's rendering or if it's sending a big amount of data to React to render, then I'm using useDeferredValue. So I guess what a dev could do at this point is look at their code and see, is there any performance block? Is there a large rendering task anywhere? And see if we could insert a React 18 concurrent feature there.

Noel:
Gotcha. Gotcha. Awesome. Are there any other perform big performance improvements or tools that devs could use for performance improvements in React 18?

 Shruti Kapoor:
So another one that actually comes out of the box is automatic batching.

Noel:
Oh cool.

 Shruti Kapoor:
And so basically the idea here in automatic batching is, let's say that you have a few different set states. Previously React was actually batching the set states that would happen within an event handler. So when you click, you have like five different set states you're doing, that would all be batched. But anything that happened outside it, would not be batched. And so this was a big performance drain as well. Going forward with React 18, any state update actually gets batched, whether it's an event handler, whether it's a set time out, whether it's a promise. So that would be another place where you would see some performance boosts as well. I think one thing that people have been noticing is, let's say you do want to opt out of it because you want to read the state right after you set it. You can kind of opt out of that automatic batching feature as well using flushSync.

Noel:
Oh, interesting. So can you explain a little bit more about why that might be a problem, like where having a batch state update could lead to weird behavior?

 Shruti Kapoor:
I think it could lead to a weird behavior where let's say you have a set state, you are updating the state. And right after that, in the same function, you are doing a console log of that state. So because they're batched, you would not see the update until at the end of that function, until that function actually executes. And maybe you have some code where you want to read it right after, like maybe you have a counter, you want to read that counter right after. In that case, you may want to force that update happening instead of waiting for the entire function to finish. So in that case, you can wrap it within a flushSync.

Noel:
Sure. I guess ... yeah. So I'm trying to think of valid use cases for that, where the answer wouldn't just be, well, don't read that from the state if you're in a given context and instead read the value that you're using to set the state. Have you encountered any instances of that where it doesn't seem like it would just be prudent to instead refactor that code slightly and change the reference to look at something else?

 Shruti Kapoor:
Yeah. Most code shouldn't have to use flushSync. Most code should be waiting for the state to update before reading it. Yeah, so it's an exception. It shouldn't be common.

Noel:
I'm sure there are cases that I'm not thinking of in my 15 seconds I've just spent pondering it, but ... yeah, yeah, yeah. Hopefully that's not a gotcha that too many new devs find themselves stumbling into. Because I could see someone not really knowing like, oh, well I'll just read the state value after I just set it here because I just set it, so obviously it would be fine.

 Shruti Kapoor:
Yeah.

Noel:
But anyway. Yeah. Yeah. Very cool. Nice. Are there any other features you want to touch on? Transitions? Automatic batching?

 Shruti Kapoor:
We didn't talk about Suspense on the server. So let's talk about that.

Noel:
Oh yeah.

 Shruti Kapoor:
Okay. So Suspense on the server is another feature that's coming in React 18. So I don't know if people are already familiar with Suspense, but basically the idea with Suspense is, let's say you have a big app and most parts of your app are fast, but there may be one or two parts where [inaudible] loading comments, there's tons of comments on your YouTube video, let's just say, and that specific component would be slow. So what you can do is with the help of Suspense, you can actually wrap that within a Suspense component. And whenever that component is taking long, that component will have a loading screen. So that's basically Suspense.

 Shruti Kapoor:
What React 18 introduces is, previously you had React suspense on the client, but only if you used React.lazy, but with React 18, you get Suspense on the server as well. And one of the cool things is, when you're doing server rendering, you actually are able to send the rest off your ... So let's talk about server rendering for one second, for those who are not familiar. So basically what happens is typically in a [inaudible] kind of program, you have your JavaScript on the page, you have your React components. React component may be awaiting for data from the API to come back. So the first thing we do is we load the JavaScript on the page. Then that JavaScript may be calling an API so we are going to wait for that data to come back. Once that data comes back, we are rendering our components. So we have our divs and whatever they're waiting for, the data. Those divs get rendered. And then once we've got everything loaded and painted, then our app is interactive, right?

 Shruti Kapoor:
So we've got basically three steps before our app gets interactive. One is, load the data and make ... render our components, and fetch the data. So load JavaScript, fetch our data, and render components. Those are the three steps. And then our app becomes interactive. To increase the performance of this, what you could typically do is you could make your application render on the server. So you do all of this heavy computation on the server, loading of the JavaScript. So basically you do fetching of the data on the server itself. And then when you ask for an input for an HTML back from the server, you actually get the entire skeleton of the app that you need. So you have your entire HTML app that you need. And then you still need to load your JavaScript to make it ... to basically refresh the data, and then you can hydrate it and that's when your application, your web app, becomes interactive.

 Shruti Kapoor:
So basically the idea is that instead of waiting for three steps to see anything meaningful on the page, you actually see a HTML output right as soon as you ask for it from the server. So that increases the time ... or that decreases the time it takes to show something meaningful to the user as well. Now, what happens is, let's say that you are still rendering on the server and you're asking for that HTML from the server, when the HTML is being generated, let's say that the component, like comments component, took very long to load, that could still slow down the time it takes to render that HTML. So let's say you've got like 50 components on your app. Everything else is fast, except for this one comment feature. That'll still slow down the app.

 Shruti Kapoor:
So previously in React 18, like previously in React, this would slow down your entire app. It could take a long time, because it was an all or nothing thing. You couldn't wait for that specific component. But with React 18, what you can do is you can wrap that comments feature in a Suspense, and so that'll delay the output of that specific component, wait for it to load, but the rest of the page gets shipped already. So we are starting to show the user a meaningful page much faster than we were before if we have a component like this, that's usually a bottleneck. So that's basically what Suspense on the server is. So you can actually suspend a component on the server when your server rendering the HTML.

Noel:
Gotcha. Gotcha. And that's a component. Is it a Suspense component or ... it's not like a traditional hook?

 Shruti Kapoor:
It's actually ... yeah, it's a Suspense component. So you're wrapping it within like a Suspense component. Yeah.

Noel:
Cool, cool. That makes sense to me. So is everything within a ... I guess, are there cases then where the suspense component is rendered on the server? Like, will it always attempt a server render? And then it kind of like ... if it's slow, it goes, oh, we'll just send this down to the client as is, and then try to render it? Or is it always just rendered on the client side?

 Shruti Kapoor:
So in this case you are rendering the component on the ... you're rendering the app on the server. So that's why it gets sent from the server. You can do it on the client as well, using React.lazy, which is like Suspense on the client.

Noel:
Got it, got it. So this component is only like if you're doing strict server side rendering and pre rehydration of the front end app where it becomes reactive. And so it's always getting state updates from the server. Is that accurate?

 Shruti Kapoor:
Yes. Correct.

Noel:
Okay, cool. Awesome. Awesome. If you have an existing server side rendered app where you're doing all that, all the React heavy lifting on the server, then just sending down kind of pre rendered views before hydration, is there much work you have to do, if you have a particular component or page or set up components that are already kind of slow, you know they're slowing down your rendering, is it easy to get those transitioned into Suspense?

 Shruti Kapoor:
Yeah, that's a great question actually. So the only thing you need to do is wrap that component within a Suspense component and provide a fallback, like a loader or whatever, and that's basically it. React will take care of everything else.

Noel:
Nice. That's super cool. Man, I'm intrigued to try Suspense, maybe more than anything else we've talked about then. Because I feel like that'd be really cool. This is just a limit of my React knowledge, is there a good way to tell if you're ... what components are causing slowdowns on your server side rendering, like in the SSR kind of processing flow? Are there good debugging tools to figure that out?

 Shruti Kapoor:
Yeah, that's a great question actually. I haven't done much work on the server side, but there is a tool called React Profiler that can help you understand which components, which JavaScripts are taking longer. So maybe give that a shot. I think there is an open thread in GitHub discussions on the working group as well about React Profiler, which I'll share afterwards. There are updates coming to React Profiler as well to show concurrent rendering as well, and how concurrent rendering is helping you. I don't know how it works from the server side because I haven't used that much, but definitely React Profiler would be helpful for understanding where the bottlenecks are.

Noel:
Nice. Nice. Yeah. Yeah. Awesome. Yeah, again, I haven't really either delved too much into complex SSR apps outside of like Gatsby and stuff where it all just tends to work pretty well and once the initial load is done or the generation's done, it's all kind of just fine. But yeah, I'm interested to know how well that tooling's coming along. Anyway, kind of back on the topic of getting ... transitioning and starting to use new features, what else, what other kind of guidance can you give devs who are excited to start using some of these tools and the new features of React 18 to help them get those integrated in their apps or solving performance problems? Anywhere you'd tell them to start looking?

 Shruti Kapoor:
Yeah. So I would probably start ... so to update basically your app to React 18, what you need to do is you need to install NPM React, React 18. And one thing you can do is, so let's say that you are on React 17, React 16 app, a good thing is that you don't actually need to change anything for React 18 to start working. Actually, backtracking that. So let's say you're in React 16, 17, or any older React, and you install NPM React 18. As soon as your NPM install and you haven't done anything else, if you open your browser and you open the console, you'll see a warning that says that you're still using React 17 because you haven't yet updated to createRoute. So the idea is that your app will still work even if you haven't made a single line code change after your NPM installed 18, which is a bit of relief for me specifically.

Noel:
Yeah. True.

 Shruti Kapoor:
So let's say that you NPM install React 18, your app would still be working fine. Then what the first thing you need to do to start using React 18 features is actually update your route from ReactDOM.vendor to ReactDOM.createRoute. So what you are doing in the background previously was we were creating a route in the background, but we were never actually accessing it ourselves directly. But starting React 18, you need to actually create a route and then use this route to render your component. And the directions of how to do this is in the ReactJS documentation. It's literally one line of coaching.

 Shruti Kapoor:
So once you've updated to createRoute, now you're actually full in React 18 mode, and you can start using concurrent features like automatic patching and startTransition or Suspense on the server that we just talked about. So what I would probably do is I would update my app from ... I would NPM install React 18, update my route, so start using createRoute, and then give a good test of my app to make sure that everything is running fine. So once I know that everything is great and there are no problems, then I would start finding places where concurrency would help my problems, especially if it's something that I was doing manually or something I was throttling or debouncing to fix. So that's number one. So NPM install, createRoute, and then make sure your app is working fine, then start using React 18's concurrent features.

 Shruti Kapoor:
So once you have all of that done, and let's say that you still want to like maybe improve the performance of how, when you render your API, you have some data ... or you call your API, you have some data coming in, you need to put that on the DOM, I would probably look at some libraries that are compatible with React 18. Next.js is compatible, so I'd probably look at some libraries that are already React 18 compatible and start using or maybe start incorporating those libraries. But I think overall, I would say that you shouldn't see any problems when you update to React 18, mostly because React 17's route is still part of React 18, so it should still work properly. But if you do get any issues, I would say enable your strict mode and see what errors you're getting in strict mode and maybe start solving those, fixing those problems before updating or adding any concurrent feature.

Noel:
Got it. Got it. That makes sense to me. Is there any weirdness with like peer dependencies or other tooling that one might be using in their project, which people are frequently running into? I don't know, like weird router problems or anything like that? Or is everything pretty compatible?

 Shruti Kapoor:
Everything is pretty compatible. A few things that people are seeing is sometimes effects will run twice in strict mode. So you may want to check your effects specifically. Maybe just turn on on strict mode and see how you're seeing, if there's any side effects or there's any issues when you are running effects. That's the only problem that I have kind of run into, but I don't anticipate any other issues. Again, if you have a library, check if your library's working fine and if that is compatible with React 18 before you update.

Noel:
Nice. Awesome. Awesome. Well, yeah, thank you. Thank you for that kind of guidance. Hopefully we can save some devs a little bit of pain and encourage people to try the new stuff. Cool. Well, I guess kind of more broadly, is there anywhere you'd point listeners or anything you implore them to check out?

 Shruti Kapoor:
Yeah. So if you're interested in a detailed overview of what we just talked about, I have written a blog on this. You can find it on my website, shrutikapoor.dev. There's an article on React 18. If you're interested in any working group discussions, which are actually super helpful, especially if you are new to concepts like Suspense, concurrent rendering, automatic batching, check out GitHub discussions. I'll link that as well. That is a great thread for understanding these React core concepts. So React team also did a conference last year, and most of these topics have been talked about in the conference as well. That is also a really great resource for understanding these concepts behind the scenes.

Noel:
Nice. Nice. Yeah. Well, we'll get as many links as we can in the show notes so people can find stuff super easily. Awesome. Well, thank you so much for chatting me, Shruti. It's been a pleasure.

 Shruti Kapoor:
Thank you so much, Noel. This was awesome for me.

Noel:
Awesome. Awesome. Take it easy.

Emily:
Thanks for listening to PodRocket. You can find us at podrocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.