Hello everybody, and welcome to another exciting episode of JavaScript Jabber. Today in our show, we've got Shooting Kapoor.
Hi, Shooty, Hey Dan, how are you.
I'm kind of on the tail end of a head cold. Hopefully I won't sound too stuffy today, but that's I'm back on at work, so that means I guess that I'm feeling better. The weather here is actually pretty nice. I'm in Tel Aviv, Israel, and it's not really cold and it's pretty sunny, but it's you know, it's a season for the snuffles. So here's what it is. So, and where are you coming from today?
So I'm in Seattle and the weather here is cold, really cold, and rainy and rainy and dark and gloomy. But I've got some lights up, actually not in the background. I've got some lights.
Up at my house, so it makes me feel better.
Good for you, Good for you, and Shooty, you are an independent content creator? Correct?
Yeah? So earlier this year I used to work.
As slack and I quit my job in April to start developer education full time. I've actually been doing this part time for a long time. I made courses on O'Reilly as well, and I really like that, So I was like, why do we need stability, Let's just drop our job and go full time, make no money, and do all the education stuff.
So you're now an independent content creator talking about what?
So I talked about React and AI and web development and JavaScript and.
Handstack and next Days and all of the good stuff.
So everything related to web development specializing in reacting cool.
And that's what we're going to be talking about today. We're going to be talking about what's new and exciting in React nineteen. Correct, yes, And are there things that are new and exciting in React nineteen.
There's actually three things in React nineteen update that I'm super excited about, which I would love to get into in a bit. But I think this updates specifically. Although this is like a minor update, it's nineteen point two, I think it has as a ton of really cool features, which is really exciting for me because it's going to help me write less code and for other people as well who are building client side apps. So I'm pretty
excited about it. This really is actually focuses on client side developers a lot, not client side developers app developers a lot, as opposed to like frameworks there are some framework features, but the main kind of audience is app developers, which is perfect for me because I'm an app developer.
When you're saying app development, are you talking about web apps or you're talking about native apps like React native or both.
So I'm not talking about React native. There are updates and reactnative as well. I just completely ignore Reactnative because I'm a full web developer, So I'm talking about app development in web. But there are updates and reacnative as well.
Interesting, So do we want to talk about both React nineteen in general and nineteen point two or do we want to focus just one one or the other.
Let's focus on point two because there's a lot to talk about, and then if we have time, we can talk about nineteen. There's a ton of features that we can get into with nineteen point two, and this is the third update this year, so there's a lot to talk about.
Cool. So, first of all, if there's so much stuff in it, and if I recall correctly, React nineteen itself was released something like almost two years ago, why is it nineteen point two and not twenty?
I think the features are kind of incremental to what nineteen has shared, which is like concurrent rendering, but like some updates on top of it, it's not a complete paradigm shift. So eighteen was a big update because concurrent rendering and automatic patching was introduced. Nineteen introduced some new features like actions, and then what we have today kind of builds on top of it. It's it's a lot of focus on async react, a lot of focus on suspense.
So that's why it's like a small update. It's like a minor update, not like a whole paradigm.
Chef, and I assume that it contains no nothing that's kind of breaking changes or significant API changes or stuff like that.
Correct, Yeah, probably the reason, Yeah, exactly.
Okay, then so what isn't you and exciting about nineteen point two.
So there's a bunch of features. Let's talk about like the feature set I introduced. So first of all, there is an activity component. I'll list ot all the features and then we can kind of dive into them one by one. So we've got the activity component, We've got
a view transition component. We've got performance tracks that come part of Chrome depv tools, which is awesome because we've been debugging with profiler and performance tracks is sort of like a magnified version of what your component is doing, so it helps in debugging. We've got use effect event a new hook, and we have React compiler is now stable, and I know I'm missing one, but I can't remember with one.
Well, you'll probably it will probably pop into your head as we talk about the other stuff. By the way, as you mentioned react compiler, I do want to mention to our listeners that we had Joe Savona and Satya from the Meta react core team, which is no longer part of Meta, and we had them on the show talking specifically about react compiler. So if our listeners are interested in what react compiler is and the details of what it does and what it doesn't do, I highly
recommend listening to that episode. I'll find them. I'll include the link in the show notes, but you can pretty easily find it if you search through the podcast catalog. But if you you know. Nonetheless, if you want to remind our listeners what react compiler is and what is it all about and why we actually wanted to.
Need it, Yeah, so actually react compiler is extremely exciting people remember, or like the way to memorize apps currently, or like the way to kind of improve the performance of your app, the first thing you would think about is, well, let me add use memo, use callback, right, That's like the first hook that comes to mind whenever you think
about improving the performance of your app. Sometimes you blindly app use memo and use callbacks to all of our components and all of our functions just because they are kind of hard to figure out where to add use memo and use callbyck, you have to use the profile to figure out which components are slow, which functions are slow, where it's the expensive calculations, and then memois that and
even then it is a hard thing to do. Now with the React compiler, memoization is given to you out of the box, so you don't need to add use memo and use callback at all. In fact, at React cons I was leading the panel with the core team and this is the question that I asked them, that can you really remove use memo and use callbacks from your code right now? And the answer is yes, it is safe to I will use memo and use callback. So reactin compiler helps to enable auto memorization, which means
that your code is auto memoiz. You don't need to add UMO use callback to make sure that it is optimizer performance.
I would even argue that it's beyond safe. It's even preferable because if I recall correctly, when React compiler sees let's say, use memo in a component, it basically bails out out of optimizing that component. So theoretically, at least React compiler, if it's you know, working correctly and does what it's supposed to do, can actually optimize your component beyond the specific manual optimizations that you implemented using memo or use memo, So in effect, it can do extra ammorization.
And if you have your own explicit use memo, you're kind of forcing it to bail out because it says, hey, you know what you want to do. I'm not going to get in your way, and then you might actually lose out on some optimizations.
Yeah, and the way they both do memorization is a little bit different. Reacompiler memoris is a different way than use memos. So yeah, like when you do manual memorization, reac compilers like you seem to know what you're doing, so you go ahead and do your thing.
Yeah, just to remind our listeners in case they forgot the benefits of memorization is like threefold, as I recall correctly. First of all, it avoids unnecessary computations. Second it avoids unnecessary renders, and third it retains referential consistency, which avoids rerenders down the line. It basically, if you think about the dependency arrays in use effect and stuff like that,
they are referential identity, not value identity. And if you get referential identity, you avoid even more rerenders than you and stuff like that. Then you would otherwise perform. And I think even the rendering engine itself, when it sees the referential identity, it knows to cut out and not totally not traverse certain parts of the v doom tree because it can immediately identify that nothing has changed. So you're effectively making the entire system just basically faster and more efficient.
Yeah, And the given example of what that means is, let's say you have a function where let's just say you're calling console log or fetching an ampair or whatever, just simple function, and that function has a dependency of use effect. So what referential identity means is that when you haven't added any callback or things, every time you render that is a new function. So when reaclub said it, it's like, oh, dependency of use if I change, so I need to run this effect again. So this way
you're running effect multiple times. If you have a function as a dependency. But if you add a used callback to that function, now React as memois that and now it knows that this is the same reference as previous time, so it won't rerender if nothing changed. So that reduces the amount of times you you ruan the use effects and again.
With React compiler, you basically just remove all your explicit uses of memo, use memo, and use callback and just let React compiler do its magic. By the way, another advantage of React compiler from my perspective, potentially even a greater advantage from my perspective, is that it's effectively a React linter. It knows the rules of React with the best practices of React, and will actually warn you if you're violating any of these React best practices. Correct.
I don't know if the compiler that I know there's the plug in, yeslamp plugin actually wants you when you're breaking React rules and in fact when the compiler, so one way to see that you're breaking React rules is when you look at the compile code, if you see that your code is intact and hasn't been memoirs, it's because the compiler bailed because you haven't followed rules of React. So that way it's easy to kind of see where you're breaking rules of React.
So yeah, yeah, it does know when you're.
Breaking rules of React, and it just like bails out for those things.
Cool. And you said that in React version nineteen point two, compiler is now officially a stable part of the release.
Yeah, yeah, so the babble plug in, so React compiler is still available as a babble plug in.
Now it is stable.
It was in our C stage for a long time and the community was wondering when it's going to be stable.
So if React content was announced that it is stable.
And what's cool is that it not only works for React nineteen, but it also works for eighteen and seventeen, so which is really cool because now you can you have backwards compatibility, so you can go ahead and remove use memos.
Oh that's interesting. I didn't know that. So if you've got a project that's built on top of React eighteen and you don't feel like an upgrade you can. Basically what you're saying is just drop in React compiler and hope for the best.
Yeah.
Yeah, I mean you can install a babble plug in and your compiler will start memoizing. I've actually added reac compiler to an app where I didn't change anything else. I just added reac compiler, just added the plug in, and I noticed that my renders, like rerenders were reduced from thirty two to just seven, which is crazy.
Wow. Yes, definitely it is. That's pretty significant. Yeah, you know, rerenders are kind of the bane of our existence, is React developers.
Yeah, and even for the ones, so even for the ones that were being re rendered, the amount of time it took to render that was reduced as well, so the height of the graph like in React with when you look at the graph of the components, the height of the bar itself was lower, so it took lesser time to vendor by just adding React compiler, which is crazy interesting.
We have a React eighteen projects where I work, and upgrading is not trivial because it's kind of it kind of shares the React library instance between multiple micro front ends, so we kind of need to upgrade all of them. In order to upgrade one of them. That's the way it's currently implemented for us. And being able to just you know, drop in maybe React compiler to see some performance improvements should be pretty interesting something I should definitely look into.
Yeah, and the newest plug in So with React nineteen point two, the es plugin also got an upgrade, so it's v six now and it also has.
React compiler rules built in.
So I haven't actually used the plug in, but my guess is that it also warned you when you're breaking rules of reacty.
That's really that's really useful. So okay, so one great thing about React versus nineteen point two is the stable React compiler. What else?
The other thing that I'm excited about is the activity component. So this component is really cool because one of the biggest things that bes app developers have been doing is storing the state of where we are in the app, especially a component, and then resuming from it. So an example would be, let's say you type something in search and then the user clicks away from search and then they open it back again.
You kind of want to show them what they had type, right, or you.
Want to kind of keep the results that they were looking for now. Currently, the way to do that or pre nineteen point two, is by storing that state and then when the user pops up again and you check if the component is open, and you reload from that state. With nineteen point two, this activity component actually gives it
to you out of the box. So all you got to do is wrap your component in activity and it understands to store the state, and it's actually going to give you that state that you've written in the text input for free, so when you open and close and then open again, you'll see what you've stored so far.
So I built an example component with Netflix where you.
Know how in Netflix when you are on a or even YouTube actually, but when you are on a when you're watching, when you're on the homepage and you're watching a trailer, like when you have it on an item, the trailer starts playing and then you move away, and then you come back and the trailer restarts.
I hate that. I wanted to continue from where I was because.
Actually that's what YouTube does for me, and sometimes I really hate it, yeah, because it starts playing muted when you hover on top, and then when you click it, it starts playing with full audio, but you're already somewhere inside the video, so now if you want to hear it from the beginning, you kind of have to rewind each and every time. It can be annoying, exactly.
I hate that, and in Netflix specifically because like it starts like I want to see the trailer, yes, but it starts off and it's loud and everything, and then I move away and then it restarts the trailer, so I kind of want to continue from where.
It was working.
Yeah, that I definitely agree with.
Yeah, And so I added So I made a Netflix clone and I added activity component to it, and that's all I did.
So I had, like a trailer, it would AutoPlay.
When you have it on it, and then when you move away, it would stop playing, and then when you come back, AutoPlay again. And all I did was add activity to that component. And then when I hovered away and came back, it remembered my state, so it knew how much video was played, which was cool.
Because I had to do nothing else to fix that and it was so awesome.
So just to understand correctly, so you kind of wrapped your component in an activity component, kind of like what you used to have with higher order components. My understanding, and what state does it store the props that are passed into that component.
It remembers your dom state basically, So like when you're playing the video.
It's the DOM state or the v doom state.
The vdom state.
So if you have a video, the amount that has been buffered, the amount that has been played. It remembers that same with like input, if it knows that you have put something in, it remembers that same with like
scrolling a feed. So another thing that you could do is if you have a sidebar and you've got like ten different items and you've scrolled down to let's say the fifth or sixth item, and you're on the second or fourth page, it remembers where in them you are, like where in the scroll position you are, so it remembers that. So I think it's beyond props because these are not props that you would pass to your component. This is just coming from downstate, right, So it remembers.
Your state, I understand. So it's kind of like freeze drawing the component state. I assume stuff like all the data that's kind of stored in hooks is somehow preserved between calls or between rerenders in a sense, I would definitely have to look at it. I understand what you're saying, but I'm still kind of wondering exactly what it does.
So it's definitely something that I will look into following our conversation, because it's, like you said, it sounds like a very useful functionality that you're effectively getting for free, as it were. Yeah, that's really cool.
Yeah.
Are there any gotchas though with this kind of thing if you run into problems or issues like that can bite people if they use the activity, Yes, because otherwise you might just wrap your entire application in this huge activity at the like at the root of your v doom tree and hope for the best.
Yeah.
So, actually, one of the things that I noticed when I was implementing this video player component was that when I hovered away, sometimes a video keeps playing. It's not consistent, but sometimes the video will keep playing. So one of the things I had to add was, now, because the video is in the dom and React doesn't actually have control on the dorm, it only has control of a
v doom, so sometimes a video keeps playing. So one of the things that I had to do was make sure when activity was make sure that in my component I add a new hook called use layout effect, which actually stops the video from playing when the component has been unmounted. So sometimes there might be weird edge cases when your component has been unmounted.
In activity, Okay.
I also assume it has a certain amount of overhead.
Yeah, I mean I can assume that.
I can understand that because your components are kind of in state, so it can definitely have some overhead, especially if you have like multiple different tabs and you've got like data loading in each of those tabs. I have an experimental with that myself to know what the implications are, but I can totally imagine that could be the case.
Also, how many levels down does it go? I mean, like I said, what happens if I put an activity wrapper around the entire application? Is it like preserving the entire state of every subcomponent in the v doom tree.
Wow, I haven't tried that. That would be fun to try.
I imagine, like your app probably just breaks at that point. I don't think your state would be restored, but that would be fun to try. Like have like maybe like ten different inputs and just put activity on top of everything.
Interesting anyway, like you said, it sounds really interesting and potentially very useful. So this is definitely something that I'll look at and play with after our conversation. Well, probably not immediately after because it's actually pretty late here in Israel, but you know, maybe tomorrow. But it does sound really really interesting and, like I said, potentially very useful. Anything else about activity before we move on to your next favorite thing about React nineteen point two.
So I think activity is really cool because a lot of the demos that we saw at react on for showing using activity to kind of freeload data. So one of the cool things is imagine you have two tabs you put your opponents something that actually one of the things that activity is helpful for is replacing conditional rendering.
So what we did initially was we have let's say through tabs, and in one tab we render if the tab is let's say home, and in another one we actually render a list of posts, which would be like a post tab. So typically what would happen is if you have conditional rendering, you load the first component the first tab. Then when you switch to the second component
is when you load that component. Right, So you'll see like a loading screen when you switch to the second one with Activity, what you could do is you could wrap both of those tabs within Activity, and so when you switch between the two, the second one is already ready because it has pre rendered your data.
So that is something that Activity is really helpful for as well.
One caveat though, is that if you have data rendering in user effect, it will not work because Activity doesn't actually mount your effects or it doesn't actually run your effects until the component gets mounted. But if you have like a suspense powered component, like for example, if you're using use or if you have next yest data fetching, then that will work, and suspect like that will work in Activity sort of preload your data before you even move to that component.
So that's really cool.
I assume that well, certainly, if you put it in suspense, then it functions asynchronously to the rest of the application. But because otherwise I don't know if Activity is like a synchronous by default or if it needs suspense for that, because if it's not a synchronous, then you might be getting in the way of your primary content.
No, so you don't need suspense for it, and anything that is rendered in activity is actually a lower priority than everything else. I think you mentioned adding suspense, and one of the differences between adding suspense and activity is that when you do add a suspense, you would actually see a fallback as the data is loading right while when you add actually activity, that component is loaded and then the other component actually gets loaded in the background
on lower priority. So your current component still has like the component that is visible still has higher priority as opposed to the component that is in the hidden state. So activity actually gives you like two moods, a hidden state and an active state, a visible state and a hidden state, so the visible state components have higher priority than the hidden state components.
Yes, I'm looking at the React documentation right now and I'm seeing it. So basically a mode attribute that can be set to either the string visible or the string hidden, and like you're saying, when it's hidden, it's lower priority. Essentially a synchronous I assume, and lower priority than visible content.
Not surprising. Interesting, Yeah, I guess that's another one of the benefits that we get from the whole refactoring of React to use fibers instead of the previous surrendering engine is that now they can really control to a fine grained degree what gets read when. Yeah, and that provides a whole lot of opportunities for optimizations such as these.
And you can pause and restart and like pause and resume your rendering when you need it to be. I think one question that people often have, so basically the way activity works is that it actually adds a display none to the component. So one question that people usually have is it any different than just adding display none. One advantage is that it actually restores your state. Second
is like it pre renders your data. But another example, another advantage that I noticed is that when I add display none, just display nan through CSS versus if I add activity. There's a difference in LCP as well, so display none takes longer to load as compared to activity, which was very interesting.
I assume, Well, it's interesting to look at what actually gets rendered into the dome itself when activity is used. Are you saying that when a is hidden, it renders into the dome with display none, or it achieves the same effect as a display none but without using display none, So.
It actually uses display none. So let's say that you have two tabs home and post. If you add activity and you move from home to post in the dom, what you would see is that it adds a display nune to the component that is hidden, and then when you move back and removes display none. So it's literally adding that display nne style to the component. But the question also arises, like, well, is it the same if I just add display nne and not add activity. So what I've noticed is it's different.
Yeah, well, I'm not surprised that it's different because well, at the dome level it might be effectively the same, but at the v dome level it's different because if you just add or remove display none, the v dome does the same thing that it would do either way.
The vedome does not know or care about display none, whereas with activity, you know that you're going to be putting display none, but you also know that you can avoid certain amount of work and comparisons and stuff like that at the vetom level because you know that this
stuff is not going to be visible anyway exactly. So I assume, again I'm guessing because I've not actually played with this mechanism yet myself, but I assume or I'm guessing that this is what actually what's actually happening really really interesting. Definitely something that I should play with.
Yeah, I'm actually very excited about it. I've added to like a bunch of my apps and oh my god, it's so nice to like not have to think about adding this UX state and storing them and then refetching from them. It makes it makes life as a app develop much easier to focus a lot on like UX improvements, which.
Is really cool.
Yeah, it's it's about the whole. It's about two things really, if I'm saying thinking about it this way. First of all, it's about that declarative aspect of React, about you know, in telling React what you want done, rather than explaining
how to do it. So rather than using all sorts of hooks and whatnot in imperative code, you just you know, like with suspense, you drop it into your vdome tree and your your componentry actually would be the better term to be use in this context, and then just reap the benefits. I do see from looking at the documentation that activity is kind of related to view transition or impacted by it. So maybe it's worthwhile to transition unintended
to view transition. Yeah, so what can you tell us about view transition?
Yes?
So view transition is actually really interesting. It is still part of the experimental part release of React. It's not stable in nineteen point two, but view transition was one of them main features that were shown and React on, so I think it's worth talking about it, especially because activity and new.
Transition kind of go hand in hand.
So the thing that you transition does is it adds the CSS animating effect to any component that you wrap it in. So, for example, you've got view transition on a component where let's see, you've got the same video player.
Kind of component. You're watching trailers.
When you click on it, you want to show like a nice zoom out effect. So you can add view transition and then you can give it what kind of animation effect you wanted to do, or you can just leave it as default and you get like a nice fading effect.
And I think it's if I might interrupt you for a second, it's first of all, I seem to recall it. We discussed this in a previous episode of JavaScript Jabber. I need to look and see when and then add the appropriate link to the show notes. But it's kind of important to understand or to note that few transitions or a browser dom feature. They're not a React feature, They're implemented by the browser itself. So the browser these days is able to animate your dome from a certain
state to a different sort of state. And the example that you gave is the kind of the canonical example of like the Netflix type user interface where when you click on a particular video, that video expands to cover the entire display because you're going into that particular movie or TV show, whatever, and hopefully my dog is barking is not creating too much background noise, And like you said, it can animate from one state to the another, something
that in the past people would need to jump through a lot of hoops in order to be able to achieve something like that. Now it's basically built into the browser. Now, remember we actually had Normozentae who actually took over the spec in the W three C for this functionality. I think it was originally done by Jake Archibald, and then I think Noah Mozenthal took it over, and as a recall, we actually had him on the show to talk about it again in the context of the browser itself rather
than in the context of a particular framework. React is not the only framework that has support for it. I think there is also support for it in Swelt. It's a recall and solid I think. So it's not uniquely for React, but it's really nice to see that React is now as built in support for it with a view transition component that you can just wrap your components in. So can you elaborate on what exactly that view transition component does?
Yeah, so you explained it perfectly.
It is basically used for animating from one state to another. So an example that we have been talking about is the Netflix app. So when you actually open the trailer and you see like this nice like effect like fade in effect into the next page or the next component, that's what.
View transition can help you do.
So now instead of having to manually add an animation, you can wrap it with the new transition.
It ass the classes.
I think it's a view transition all and new which actually adds the slide in and slide out or like fade in and fade out effect, so it gives you animation out of the box.
Yeah. I think that's probably the best example.
So you would have certain you would have components wrapped in the view transition component, and then when you want to create that animation, what do you do? Do you replace the components that are contained within the view transition, do you do something else? What exactly do you do in order to trigger the animation?
Yeah, so now to trigger the animation, that's a great question. Basically, what you want to do is let React know when you want to start transitioning to the next component. So what you do is, let's say that you have a button that actually initiates so like when you click on the trailer, the button actually navigates to the next element.
That's when you want to wrap that button or that on click handler into a start transition and that will React know that at this point I need to start the transition of actually adding the like removing the old V transition and adding the new view transition effect, and that's where the next animation comes in. So you need to actually trigger the view transition by using a start transition function and that you wrap around whichever element should
trigger the next component. So, for example, if you have a button that actually opens a new component, that's where you were added.
Understood makes sense, So React has to know when you're actually instigating that transition, when what you're actually transitioning on.
Yeah, exactly, very very cool.
So what is the relation between activity and view transfer?
So I'm trying to remember, Like, let me look at the doc to see what it actually talks about.
It's not that important if you don't remember off the top of your head, but I seem to recall that there is some sort of a connection there.
Yeah, I know that the coherent hand.
I'm trying to remember, like, what was the example that was showed in the conference and.
It says, oh, it's actually under caveats. It says, if inactivity is rendered inside of you transition and becomes visible as a result of an update caused by start transition, it will activate the view transitions and to animation. If it's it becomes hidden, it will activate its exit animation.
Yeah.
Actually, like activity works as the start transition effect. So when you have that component come in and it's been wrapped in new transition, that's when it starts animating in so the view transition has started the transition when activity is visible.
Makes sense, makes sense because effectively, that's probably what you want. Yeah, okay, okay, then obviously our listeners, you know, one of the downsides of a podcast is that it's an audio medium, we can't actually show you stuff. I think Shreuty is doing an amazing job of explaining just verbally. But if you want to see then the React website has a lot
of actual examples. Or alternatively, if you use something like a cursor, you can tell it write an example for me of some code that uses this or that feature React, and then you can look at what it created.
Yeah, if you do that, the only thing I would do is give it the documentation and then tell it to create an example with the source of the documentation, because I've noticed that when I give it create especially with this newest updates, when I tell I haven't tried this with cursor, but I've tried this with plot, but when I tell it to create an example, it actually doesn't give the accurate results.
So give it the documentation.
Yeah, but it gives inaccurate results with complete confidence.
Yes, I wouldn't know.
One thing I wanted to say is the Netflix example that I'm talking about that is also on my YouTube channels. So if you're looking to see how like what the code behind that is, it's also on my YouTube channel.
I'll leave link to that.
Excellent that that will be awesome. Yeah, so show some love and support for shooting in a new end of way exactly. So we talked about the REAC compiler, we talked about activity, we talked about fut transition. What do we want to talk about next?
So there's two more things that I want to talk about, and let's talk about use effect event, which is the only hook that comes in this.
Really.
Use effect event is a hope that I am super excited about because it helps to clean up user effects. And I have seen so many places where this could be useful and so many mistakes that happened with the use effects. So I think generally use effect could use some love, and use effect event comes at the right time.
So what use.
Effect event does is it helps to remove reactive and non reactive vas use out of use effect. So we were talking about this earlier where if we have a dependency and use effect, anytime that dependency changes, we rerun
the use effect that causes a lot of rerenders. But imagine if you have a perfect example for this is imagine if you have a page where you just want to lock the impression of when the user landed on this page, and then you want to lock some other aspects of the page as well, like what is the user's name, what time is it?
Things like that, right.
So additional things that you want to log as soon as the user lands on the page. So in that case, when you add a use effect and you log analytics on that use effect, what you would be doing is you would be adding like name and time. Maybe not time because times so dynamic, but name and like page and route and things like that.
Basically funderstill correctly. And I looked at some examples. Unlike the previous two which I haven't looked at, I did look at this one for some reason. And when you're using a certain value in user effect, React kind of requires you to include that value in the dependency ray. If you don't, you will actually get squigly lines for it and React with complain again not at run time, but it build time, React could actually complain about it.
And therefore, if you have a certain value, if you use a certain value within your use effect, you're kind of forced to include it in the dependencray. Problem is that if you include it in the dependencray, every time that it changes, it forces that use effect to be reevaluated. Yeah, which is may not be what you want, like you said, if I'm only using that particular value. Let's say is an example that you gave to write to the console, I don't I want to when I write to the console,
I want to use the current value. But if that value changes, I don't want to rerun users effect just because there's a different output to the console. So is that correct?
Yeah, and that's that's exactly correct.
And like you would want to, for example, log impression only once when the user has landed, and even if the path changes or something else changes or prop changes, you don't necessarily want to lock the same impression again. It could be a false impression as well, like you are adding data that you don't need. So in that case, like you said, if you add that in the dependency or a which react will actually force you to, you will be causing that function to run again and again,
that effect to run and again again. So what use effect event does is you can move the non reactive values. And non reactive value basically mean things and dependencies that you don't want to rerun your effect for you don't want to react to that value, So you can move a non reactive value outside in a use effect event. That's why it's called use effect event because it's used to move event logic, which is like items that change that items that you just want to read.
The value out of you don't want to react to it.
So you can move those values, for example, in this case, maybe the past name or maybe the user name, things like that into a use effect event, and then you use that use effect event within the use effect So it's actually like a helper hook for use effect and that actually prevents you from reading the dependency or like reading the reactive values or reading the non reactive values, and prevents you from adding that to your dependence, which
reduces the amounts of time you read, render your component, and rerun your effects.
I remember or that in the past, when I prior to this ertion of react, when I wanted to achieve similar effect again pun intended, I would use AF for it. I would generate references to values and then even if I put I have to force to put the reference inside the dependency or a reference itself doesn't change the
value that the references does change. So this is kind of a way to circumvent the problem, but it's it's kind of it almost felt like kind of a dirty trick or a cheap trick, like essentially using refs for values that shouldn't impact that can change but shouldn't cause a rerender is doable, but kind of felt dirty in a sense, like this is not what refs were originally intended for exactly, and now we can be much more
explicit about it and not use a hack. Yeah, precisely cool, So that's really nice, it seems though, to be honest, it seems like something that is really helpful when you actually need it, but not something that you might be using all the time. Like almost all the examples that I'm hearing about end up talking about console.
Logs, So yeah, I think you're right.
Like, the biggest example that comes to my mind is about analytics and passions, because that's the one where you don't really want to react to a dependency that you've added. Yeah, it's kind of anything like when you need that effect, like when you need that hook that is the right hook, but otherwise that hook is not very commonly used.
So anything related to observability, as it were. That way, you want to observe current values, up to date values, but you don't want to have to impact the actual behavior of the application because you're just observing it. Correct interesting. That's that's I think. I think that's a good point of view on that on that particular topic. I think that's that sounds like potentially the primary use case really very interesting. Okay, then we are I think we are. Well,
we still have some time. So do we have more items? Now?
One one you can talk about that I'm super excited about.
Okay, go for it.
Probably the most exciting thing in this release is the performance tracks in Chrome death Tools. So if you've been debugging React apps, you know that you need to install an external extension called React death Tools, which gives you profiler and I think it gives you components as well as part.
Of Yes, it does. It provides you a component view that's kind of similar to the built in Elements panel. So you've got a built in component spanel which you can you're you're basically seeing components and their and their state and their properties, which is really useful for understanding what the vedom actually looks like at any point in time.
And like you said, you have something that's kind of similar to the death Tools performance tab, only it looks at component re renders, so you can use it to identify excessive rerenders. I've used it on multiple occasions to identify excessive rerenders and try to mitigate them.
Yeah, so those tools that really help perfectly just a flame chart, yeahs. And that profile tool is very helpful, especially for figuring out how many times your component re rendered, and that is the tool that I was using when I was working with reac compiler to figure out when the compiler has had it just how many times it reduced the rerenders. So that tools are still really helpful.
But there is a now default tool that comes with Chrome Deaf tools if you have React nineteen point two install, which is the performance tracks and that is part of the performance tab within Chrome, so you don't need to install anything else, which is really cool. But what this does is when you inspect a component, Actually what you have to do to enable this, this is a little bit of gatcha, which not that easy to understand, not that easy to see, is you actually have to record
the performance. So there's like a recording tab you have to record, and then you can like go through your app and do what you need to do, see like which clicks and whatever.
You need to record.
When you stop the recording, that's when you'll start seeing the performance tabs. So in the performance tab of Chrome Depth Tools, now you'll see two new tracks. They're called and they're called Components, and then they're called Scheduler.
If I remember the name correctly.
But they have a little React logo, so that shows you that this is coming from React nineteen point two. But what they actually show you is, let's say you clicked on an element and then you're fetching the data in the background, and then you're waiting for You're like you have got a loader coming in and then you're waiting for data to fill in, and then you have got some like changes in the DOM that's happening, changes
on the UI that's happening. Now that performance track will actually log and show you all of that on the track itself, so you can actually see at one point you clicked, how long did that take? How much layout shift did that cause? What is the blocking part of this process? So when you're actually fetching data, that could be part of blocking. So now if you add suspense, it will show you like this is where suspense boundaries
came in. So this is a really cool way to see what is your component doing when you've made an interaction, when you're doing something with it. And it's really helpful to see exactly in which phases your component is blocked, in which phases the React vidowm is actually committing. And it is a really cool way of debugging the React apps, so much better than profiler.
Interesting. I assume it's only active or only shows the sexual information when React is in the development mode. That's probably FLUE because otherwise I assume that there would just be too much overhead.
Yeah, it'd be weird to show that in for production apps. I haven't tested in production, so I'm not sure, but I assume.
That's the case.
I'll definitely take a look at that one. You may or may not know I'm something of a performance junkie. My current My current role is more let's call it a general I'm a principle engineer at a SI sense, so I deal with a lot of stuff, nothing not specifically having to do with performance. But my previous two roles was a performance tech lead, so i'm and i'm
still on the doctor. Three CEE were performance working group, so so where performance is kind of my jam, So if there's this new functionality in the performance tab and dev tools, I definitely want to check it out and thank you for pointing it out. It's really exciting. It's something I'll definitely look into.
Yeah, you might really appreciate it. So it's available in nineteen point two. You don't have to do anything, only kind of I spend a lot of time like figuring out where these tracks are. The only kind of gotcha there is you have to record performance and then see it, and then you'll see it.
Now, have you done a video on this?
Yeah?
So in the React nineteen video I launched, I do show how to inspect an element with performance tracks.
And do you also provide like a guitub example application that you can actually play with with this stuff?
Yeah?
So actually in the video link there is a example as well.
Have we put up the video so it's easier.
No, you know, we can put the link for our listeners, but I really don't want to show the video because then our listeners are kind of missing out. I think it's sufficient to say that we will definitely put a link to to shooties content, and you're definitely encouraged to go out and check it out and what you know, like and subscribe right, subscribe. Yeah, you need to get into that game.
Like subscribe and comment and hit that bal.
Icon so you never miss do you know?
It's a notification from shut Kapur.
Excellent, excellent. We do have something like ten more minutes, I think maybe even fifteen. So is there anything else we want to talk about either about nineteen point two or nineteen in general?
I think one of the big kind of themes about nineteen, especially as you'll see in the content stocks, is async React, which is something that I want to dive deeper into, which is we have been using use effects to call our APIs if we don't have any other frameworks or data catching libraries, which has just been the general way, right. But React nineteen introduces use hook, which is used to
resolve promises. So with nineteen point two and the conference talks that we've seen nineteen point two's React conference, a big focus has been how to move away from data fetching and use effect to actually using React the ACYNC way, which is by fetching data through the use hook, wrapping it with suspense, and then perhaps adding animations to view transitions and activity like showing in and out through activity. So I think with React nineteens released, the way we're
going to be fetching data is changing. So I am very excited to try that out. That's going to be another video that I'll do on my channel in January. But I think the main focus is that we're going to be be changing the way we've been fetching data in React nineteen.
I totally agree, and interestingly it's going to be one of my picks. But I'm actually giving a talk at the upcoming React next conference in Israel.
Oh cool.
It's yeah, it's Israel's largest front end conference. It originally was just React specific, but it has even though it's retained its name of React next, it's effectively become kind of a general purpose front end conference, not just about the React ecosystem. I think we're going to have something like somewhere between one thousand and twelve hundred attendees. It was like so sold out within a week or something like that. Wow, I'm actually, if I you know, I
might brag, I'm actually beyond giving a talk. I'm actually giving the keynote. That's awesome, Yeah, which is kind of amusing because I'm not talking about AI. But you would think that any talk, any key note that front end conference these days is going to be somehow about AI not mine nice. But the reason that I'm bringing it up is that the topic of my talk is actually
about our PC if our listeners are interested. It's kind of reminiscent of the conversation that we had with Ryan Carneato and Tennor Lindsley a couple of episodes ago about RPC and how it's kind of making this significant comeback in modern front end frameworks or full stack frameworks to be more accurate. And the reason that I'm bringing up is that one of the things that I'm showing is using ORPC, an RPC library within a React component to talk from the front end to some EPI on the
back end. And RPC makes access to back end services look like function calls, kind of similar to what next js does with the server actions and React server components. So it's kind of similar in that respect. So you're calling a back end function and rather than getting a value, not surprisingly, what you get back as a promise, and now you can just use it inside use and it makes it look exactly like a function called you just
wrap it in use effectively. You might say that in this regard, use is kind of reacts replacement for a weight in client side components. In React server components, you can actually use a weight because they're running on the back end and there's no problem with that. But on the front end, because of the way that React works, you cannot actually use a weight in the component itself. You have to kind of wrap it in use affect
or something. And now you can just use use instead of effectively as and a weight inside client side components. So that's really cool. The demo that I'm showing is effectively just calling this function on the back end in order to get a value and using that value in the render to in the rendered component, and I use use, so this way I get and it's wrapped inside suspense. So this way it makes the call to the back end.
While it's waiting for the content to arrive. From the back end, it shows the fallback and or the placeholder or the loader or whatever. And once that value arrives and it immediately rerenders using that that value that was received from back end. It's really cool and it sounds it's one of those things that's much easier to show than to explain verbally, all I can say is it's it's very readable code, much more readable than if I had to use use effect instead.
Yeah, that's that's a cool example.
Like, so you're returning data through an RPC call and because it's a promise, you can.
Use use it exactly.
Oh, that's cool.
That's kind of like how tanstax start does so actions as well. So so actions are just RBC call and typically you put that in your loader, but you could totally put that as a user as well within your reaction.
Yeah. It actually is a little bit tricky because if you're not careful with it, you can get into kind of this rerender loop because every time the component renders, you get a new promise, so you kind of need
to be careful about it. And one of the great things about something a library like ten stack query is that it does the automatic dedoping or cashing for you and make sure you get the same promise each and every time, so you're not getting into these kind of rerender loops if you're using use So it can be a little bit tricky if you're using use directly, which is why i'd probably recommend using something like ten stack
query in these types of scenarios. And and by the way, going back to my example of r PC, there's actually I think a ten stack query wrapper for for r PC, so you can use them together really really nicely, or just use ten stack start if you want to have an RPC capabilities in your full stack framework. Cool. Yeah, it's it's one. It's something that I discussed at links with our common friend. We found out that he's a
friend of both of us. Jack Harrington. Great guy. Yes, yeah, I love this guy and he makes amazing content as well.
He makes amazing content.
Yeah. Anyway, so yeah, I really like YOUSE. I think it will definitely change the way that people write client side components in React, although they're like I said, there are few gutchas there and people will need to get used to it and learn how to properly use it again pun intended.
Yeah, the suspense is building up exactly.
Yeah.
I think news with suspense and new transition and activity is kind of the future of React and I'm very excited to see it in action.
Yeah, I totally agree. I think that Suspense when it landed, opened up a huge amount of possibilities that this whole thing about asynchronous reactivity in React is the sea change, and we're still experiencing the outcomes and the benefits of these changes, and also the added complexities associated with them. It's definitely a different model to learn and to understand with regard to how React actually works and what happens. When Okay, we're close to finishing our time going to picks,
you know what I'll give us. I'll give us ten or ten more minutes to talk about React stuff before we go to picks. Is there anything else you think we should be talking about in the context of React nineteen.
I think those are the biggest things that comes to my mind. I'm super excited about React compiler being stable. I can't wait for removing I can't wait to remove all the use numbers and use callbacks. That's the one that I'm most excited about. Activity is a component that I am specifically excited about because I've routed a lot of apps where I've had to actually store the state so I can wait the refactor my apps, do you.
Consider Okay, so per my understanding, who's client and use server even though they need a full stack framework in order to work, which means that they need either next JS or ten stack. You would consider them to be part of React though, right, so they are part of React.
They are directives, but they I don't think they were tan stack not.
Oh yeah, ten stack has its own alternative, I think.
Yeah, so tanstyle just has like creates so a functional with just the same as youth server. And then you don't need to use used client because everything is client first. I think the only work.
In next year understood and use cash. That's a next GS thing. That's not even a reacting.
Right, I can't remember. I know it's a next gest thing. I don't know if it's like a React things use cash. And then there's a new one which creed a lot of controversy in trying.
To or use workflow. But that's not even the next GS thing. That's a verse cell thing. Right.
So there's so many use hooks, use directives, and the only place that I've been I've seen them being used is next year.
Do you remember the original one? Though? You strict that's that's where that's that's where they all come from.
Oh yeah, that's true. Now that's a standard.
Yeah, well that's part of JavaScript. Even that's not even React. That's the JavaScript itself.
I guess that's where it comes from.
You're right, yeah, that's that's that's the original, that's the OG exactly. Now we've got all but it's getting to the point where, if this keeps on going, we'll probably need some standardization body to ensure that we don't get conflicts on their various uses.
Yeah, and that's the thing, right, Like, these are not standards, they're not type safe, so you have to remember to add the directors to the files.
It's a lot of mental overhead.
On the other hand, they're declarative, which I can appreciate. Know that originally they were actually if you I don't know if if you know this or remember this, but originally they sought to use the file names, so instead of having used server and use clients, they thought about having a client dot tx and server dot tsx in the actual file name. And then they decided that they needed greater granularity and have it more declared narrative in the code itself rather than an external place like the
fine name. I think that Swelt, on the other hand, does intentionally use file names for these sort of distinctions, so it's a different take on the same approach, but On the one hand, I really like the declarative approach, basically saying what you want rather than how to actually do it. I am concerned about, like you said, all these users because they're kind of outside the scope of
the language. The fact that it's a string intentionally forces the language to kind of ignore it and being an inline string, and there's no standardization around it, and it's and it's an interesting question. I assume that the linters will be updated and modified to take this into account when they're parsing the code. I see no reason why not.
But I have to say that I was thinking at one point or another that if decorators would have already been standardized as part of JavaScript and not just as part of Typescript, then maybe we should have used decorators instead for these sort of things. That's true, although decorators require classes and React now is mostly class less, right, so you know, so it's a problem, yeah, Lie Stard, Okay, we are more or less at the end of our
content part. Is there really anything else we should be mentioning in the context of React that we haven't Maybe things that you're excited in the in upcoming versions that you're hoping for the reacting to introduce.
Yeah, so React, like I said, is going to move into this like ACYNC React version, which is going to be the future of React. I'm pretty excited about it because so far we've had to depend on frameworks to fetch our data. Now it starts to kind of come back and to React and we don't have to actually need a framework to use things like use, which I'm super excited about. So that's something to keep an eye
out on. How data fetching is going to change and how loading components and reading from these promises is going to change with the future of React.
Interesting. I would like to see some sort of built in We are kind of we kind of have it in with React server components, but I would like to see more explicit support for streaming built into the framework.
It actually has to go with another one of the examples that I have in my talk, which is actually using a generator on the server if you're familiar with generator functions, So you can actually wrap a generator as kind of a server function, and then you create a stream of data coming into the client and you can, let's say, re render a React component whenever you get an update from the server, which is really really cool.
Yeah, I need to be going through the next sofait.
Yeah, now right now I need to do something. I need to use a use effect in order to achieve it. It would be great if it would somehow be better integrated. I guess that React the core team would say something that you effectively can get it using reacts server components already, but I would like to see something nicer, a real stream type implementation.
Have you tried rendered to pypable stream?
I say, I have to say that the O RPC implementation is just so nice. I can show it to you after we finish our conversation. It's just so clean that I'm happy with it. But if there are alternatives. After a show, you you can tell me if there are potentially nicer built in alternatives and React itself okay. Then, So to finish up our show, we have our picks section, and in our picks we just shout out what'sever interesting for us or to us. It can be technical, it
can be non technical, any topic that we want. So I'm going to start, because that's what we do. We let our guests go last. Oh. The first pick I had is one that I already mentioned is the fact that I'm the keynote speaker the upcoming React Next conference. It's actually scheduled to take place on December fifteenth. I don't know if this episode will air before then or after then. If you're listening to the live stream, well it hasn't happened yet. I'm really excited about it. I
think I've got some really really cool demos. It's an interesting topic, one that's really near and dear to my heart, think that the comeback of o RPC is really really interesting. Interestingly enough, the very next day, I'm giving a talk, not a keynote, a regular talk at yet another conference here in Tel Aviv called no TLV. It's a conference for no developers, and this is the first time that
talk of mine. The title of the talk was actually kind of censored, i would say, by the conference organizers, which is really amusing. And when I asked them why they did it, they basically looked at me and told me, are you serious. So the title of my talk, the current title, is using heap dumps to find and fix
no JS memory and CPU problems. So I'm basically talking about how to take heap dumps both programmatically and using dev tools and whatever other mechanism, and then how to analyze them in order to find and fix memory and CPU issues. Now, why did they censor the talk title? Because the original title was taking a dump colon using heap dumps to find and fix no Jazz memorane CPU problems. So yeah, I think that was like too much for them.
Oh that's the interesting title.
You should you should see the slides that I'm using. I didn't censor the slides.
Yeah, I would like to check it out. That sounds really fun.
Yeah, I think it's going to be good talk. So I'm giving these two talks, so that would be my first pick. My second pick is a bit of news that dropped today or yesterday is the fact that the Anthropic is purchasing bun. Have you heard about that?
I have not. Oh wow, that's amazing.
Yeah, so bun has been Soldanthropic. It's becoming part of Entropics. The bun core team including everybody, is going to become Tropic employees, and they're going to continue working on the project and the project will continue as an open source project, so effectively for people who are using bun, it continues as is in fact the great news because, for those of you who don't know, Bonn was a VC backed open source company, which means that they got their money
which funded their development efforts from vcs. But vcs like to see return on investment. In the case of companies such as Versailles or maintaining nextgs, they were selling hosting services the same for by the way, Fortino, but bon had no such things. So there was an obvious question about how bon are going to be able to continue as a VC funded open source organization without an actual
revenue stream. And the LVIUS answer is they're going to be sold, and they were sold to Anthropic, and Nentropic is committed to continue to support them and continue to support this open source project. So it's I think it's good news for the open source community and for the future of bon. By the way, we had I forget the name of Bun's fund. You remember's name. We had him as a guest on our show as well. I remember, yeah, exactly, Jared Sumner, and we actually had him in a guest
quite a while when Bunn was really really new. We brought them on to talk about why he built it and what are is, what's his philosophy and his goal with his project. It's a really good episode. Even though it's it's I think it was like something like two years ago something like that. I think it's still very pertinent and I recommend to our listeners to listen to it. So those would actually be my picks for today, all of them technical, I guess. So, Shooty, do you have any picks for us?
Yes?
I will shamelessly plugged my YouTube channel. You can find REAC content more of what we talked about, all of the code examples with It's.
The name of the channel, it's called.
Shuti Kapoor, just my first name and my last name. You can just YouTube me up Shouty Kapur and you'll find myna I have like what two fifty videos at this.
Point, Like, wow, that's a lot a lot. Yeah. Do you prefer the long form or the short form videos?
I like long form because short form is very ephemeral. Maybe it hits some people and then it just gets lost. Short long form is more watchable. I feel you can deliver a lot more content in it, and you can deliver a lot more value, and you can actually show like cold demos probably in long form. In short form, it just gets like weirdly cropped out. I don't like short.
Form, so you're not the TikTok.
Generation, too old for that, But I do like short form for like quick tips. So in the month of December, I'm doing the full month of AMA ask me anything serious. So I have picked questions that people have left in comments, and I'm making a short form video out of each of them.
Wow.
So every day I'm answering one question that the audience has left me in my YouTube comments or in the shorts. If the audience who's listening to this podcast has a question, you can also put that in the chat and I will pick it up and make a video.
Out of it. So of that's awesome.
Yeah.
So, like, especially like when I've made AI videos, people have asked questions like do you still need to learn fun end in this age of AI? Or is fun and going to die because everybody's going to become a full stack developer. So there's real concerns that people have and they've left that in comments, and I'm interested.
So primate Gen made a video about the bond purchase Bianthropic and one of the things he said that here, here's this company who was into who was basically building AI development tool, and they purchased a project that's been developed by programmers by developers. So that goes to answer your question about do developers still have a role in our world.
Exactly, Like the answer to that question is, like, we're going to need people who are going to build these systems. So even if you're writing AI code, we're going to need people who understand what that front end code should look like. Like I was saying earlier, like if you use clod to generate activity code like React nineteen activity code, it is all garbage, So you need to know what is the right thing.
Knowing your AI, like knowing.
Your front and fundamentals is very important even if you're using AI to write code and build complete apps in the future.
I totally agree, right, So.
Yeah, shamelessly plugging my YouTube channel, go check it out, like, subscribe, comment, and hit THATLL icon so you get notified at the new videos. I also want to shout out code Rabbit, which is a AI code reviewer against. Speaking of AI code tools, one of the tools that actually helps and I have been using a lot this year for reviewing
my code is code Rabbit. Like I said earlier in this episode, I have quit my nine to five job, which means that all of the code I write I am the only owner, but it gets read by so many people, so I want to make sure that my code.
Is well written, it is performing.
But also it catches things like it's reviewed properly, and I'm also catching things like breaking as breaking responses and error cases. So code rapid has been really helpful in helping me see those errors, especially things that I may miss, things that I'm like writing super fast and we forget.
So great code review tool, completely free for open source tools. Check that out.
It's called code rap I totally agree. We actually use code rabbit at size Sense, so every every pr undergoes review by code rabbit in addition to manual review, and I have to say that it's it's really a great tool. Very often I find and fix most issues before they even get to be to the point where you know the manual review is required. So we still require man your review, but by the time we get there, code rabbit is probably I probably fixed like five or six
different things that code rabbit has found for me. Two things that I really liked about code rabbit is first of all, the way they kind of use emojis to indicate what they're doing, like the eyes emojis like that I'm looking at it or stuff like that, or like the thumbs up emoji. And basically they make very effective use of emojis to indicate what's going on and even
allow you to respond to their comments. Like say, if you want to basically say yes, I'm handling I've handled something, or i'm handling something, or i'm intentionally or I hear you, but I've decided to ignore this recommendation, you can kind of indicate those things your intentionality using emojis, which is really cool. So that's one thing I really liked about it.
And another thing that I really liked about it is that it also kind of diagrams you code, so even if you're getting a person to review your code in additional to code Rabbit, it can make it very much easier for them to actually understand what they're looking at, what the changes are then stuff like that, Like you said, I really like and appreciate that tool.
Yeah, And on top of that, it also adds to the summary of the pr itself. So let's say if you're somebody like me who hates writing PR descriptions. It can actually improve it for you by looking at what code you're adding, so it'll add an I summary of this was what was added these other features.
This is a code chain, so it's.
Really helpful in making a like the code view process much smoother.
Totally agree with you, So you kind of gave it already, but let's give it yet again. If people want to get in touch with you, contact you, maybe send you a questions so that you can create videos about them. What's the best way to get in touch with you?
Yeah, so the best way to get in touch with me is to actually comment on my video. I obsessed watch my videos comments and read all of them. Oh no, I know people have told me not too, but I can't stop. That will be a new Year's resolution. But yeah, you can actually leave a comment on any of my video to let me know what video you want to see next.
But you can also send me a DM on Twitter.
I'm at schutikapour zero eight my first name, last name, and zero eight, which is my birthday. I'm obsessed with my birthday just coming up in five days.
Oh you're you were born in December. I was yes, so good for you mine as well. So I was talking about the fact that I have these two conferences on the fifteenth and the sixteenth. Actually, my wife's birthday is on the fourteenth, and my own birthday is on the seventeenth, so we have my wife's birthday, then one conference and another conference, and then my birthday. So it an interesting week.
It's like sandwich between conferences.
They can celebrate and then go enjoy the conferences and then celebrate your amazing talks exactly.
So first, so happy birthday to you, thank you, and to you, thank you very much. And I guess that with that will will wrap up right.
Nothing more to add, nothing more to add.
So thank you very much to all our listeners. It's been a great episode. Thank you Shouty for coming on our show to talk about REACT nineteen or actually, more accurately nineteen point two, even though we also talked about REACT nineteen in general. And to all our listeners, thank you very much for joining us and see you again next time. Bye.
Thanks for having me