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