React Core
===

Paige: ~Test, test, test.~

Sathya: ~Test, test, test.~

Joe: ~Test, test, test.~

Paige: ~All righty.~ [00:00:00] Hello and welcome to Pod Rocket, the podcast that is brought to you by Log Rocket. Log Rocket helps software teams to improve user experience with session replay, error tracking, and product analytics. Try it free@logrocket.com. Hi everybody. My name is Paige Niedringhaus, and I am your host today for this particular episode of the Pod Rocket Podcast.

And with us today are two exciting guests from the reactor team. We have Satya and Joe Savona and Satya. Welcome. ~Uh,~ I'm sorry that I did not say your last name, but I was afraid of butchering it. So if you could please introduce yourselves and tell us a little bit about your experience working on the reactor team and how long you've been at it.

Sathya: ~Uh, sure. Yeah. So, uh, ~my name is Sathya Gunasekaran.~ Um, ~before,~ um,~ so before I joined Meta and the React team, I used to work on, ~um,~ vt, which is the JS compiler in Google Chrome. ~Um,~ and then I've been at, ~um,~ meta for over a year.[00:01:00] ~Um,~ and I've been working on a React compiler with a bunch of, ~uh,~ amazing folks here on the React.

Paige: Awesome. And Joe, please introduce yourself and tell our listeners about ~About~ you.

Joe: ~Yeah, thanks. Uh, yeah, so~ my name is Joe Savona. ~Uh,~ I've been at, ~uh,~ meta for almost nine years now. ~Um,~ most of that time working on Relay, which is our, ~uh,~ graph fuel client for React. ~Um,~ and then, ~uh,~ over the last few years working on React itself, ~uh,~ and most recently on React compiler. So the, what we're here to talk about, react.

Paige: That's excellent. So we have some listener questions that I'm going to be sprinkling in as we talk about today's topics, which is most, as you said, mostly about React compiler, but it's also ~kind of~ some of the other things that you've been working on. React server components and meta documentation and offscreen rendering, things like that.

So one of the questions that I thought would be a good lead in for you is, The introduction of Hooks and React was really a game changer for the way that developers build web apps in general. So what do you expect is going to be the next [00:02:00] paradigm shift in React? What kind of use cases are you really looking towards and building and optimizing for?

Joe: Sure. Yeah. I think the the next big paradigm shift is happening now. That is server components. ~Um, so, you know,~ I'm sure there will be a thing after that down the road in a few years, but, ~um,~ it, it's, we're ~kind of~ still right in the middle of, ~uh,~ a big shift right now. ~And that,~ and that, that's server components.

~Um,~ and I think, ~uh, you know, we've,~ we've talked about this, ~uh,~ a lot on ~like~ a bunch of different places ~and,~ and~ I think the, the.~ Depending on your background and how you approach, ~uh,~ react, ~um,~ server components may ~kind of ~register, ~uh,~ or ~like~ make sense in different ways. ~Um,~ but the basic idea is that server components are react components that can run on the server.

So with traditional server side rendering, you're taking the kind of client side react code and ~kind of~ running it ahead of time on the server, whereas server components are components that only run on the server. ~Uh,~ and ~so, uh,~ they get to run on the server where you have, ~you know, uh,~ you're right near your data, you can go, you can have async components that just, that go and you use regular Async Await to go and fetch data, ~uh,~ and then render a bunch of client components.

And the idea [00:03:00] is that, ~you know,~ you can do all your ~data,~ data loading on the server. And then figure out ~which,~ which client component you need to render. And then send just that, that component and it's ~kind of~ props down to the client and then ~kind of~ continue rendering there, ~uh,~ for interactivity and, ~um,~ And ~so, you know,~ this has a lot of analogies.

~Uh, you know, it's like if you're,~ if you're thinking, if you're ~kind of~ familiar with ~like a,~ like a Rails background for example, you might think of ~like, well,~ the stuff that you used to do in Rails and then ~kind of~ have rails hand off to react. ~Well,~ you can do that, you can do the rails piece of it on the server in React and ~kind of~ use one frame, one framework. a bunch of other kind of interesting things that server components enables. ~Like, uh,~ you can have components that can run both on the server or the client. ~So, you know,~ an example would be, ~um, You know,~ the everyone's favorite,~ like blog, you know,~ blog example of, ~uh, you know,~ markdown posts, right?

Where like if you're just viewing the blog, ~um,~ you want to, you might as well just render to the markdown to HTML on the server so you don't have to download that comp, ~that,~ that very large complicated code to convert markdown html to the client. But if you're editing the blog, well now you can have an interactive preview and use that same exact component.

And [00:04:00] that's the kind of thing that you couldn't do when you were mixing technologies, right? Whether it be. Rails and React or PHP and React or even something, ~um, you know,~ some of the other kind of, ~uh, ~uh, MPA frameworks in JavaScript where you mix, right? A different set of, ~kind of~ different code, different types of, ~uh,~ logic, right?

For, ~uh,~ like for example, for Astro or something else between like your Astro components and your React components. And when you use server components, it's all just one exact tech, ~you know,~ the exact same technology. And so you can have these truly shared, ~uh,~ components. So I think ~that~ that is a, a really big paradigm shift.

~Uh, and,~ and, ~you know,~ Still early, there's still a lot of people who are like figuring out how to adopt them. ~Um, you know,~ it's still a bit experimental. ~Right. And,~ and ~kind of ~support across the ecosystem is coming along.

Paige: ~Mm-hmm. I mean,~ I think ~that~ that is, that's a great, that's really cool to hear actually. And I, I love it because I'm a big user of Next Js already, so I've had a little bit of that with get server side props and the ability to ~kind of, if you,~ if you correctly build it, you can use the same code on the client and on the server, but ~it is,~ It is still painful at some at certain points.

So having react, ~kind of~ build that in from the [00:05:00] beginning and really support it as a first class experience is only, I see it only improving. So that's a really awesome to hear.

Joe: Yeah. Yeah. We're really excited about it.

Paige: All right, so let's get more into what we really wanted to talk about, which was React compiler. So in a recent blog post, the React Core team published, you talked about some of the new things that you've been working on and React compiler, which is also known as React Forget, it's very aptly named, ~um,~ was a big thing that I think a lot of people are interested in hearing more about. Kind of new and it's still W in a A work in progress. So maybe you could start by just giving our audience an idea of what is React, forget, and why have you nicknamed it ~kind of~ an ~auto memorizing compiler, sorry,~ auto memorizing compiler versus an automatic reactivity compiler.

Joe: ~Yeah,~ yeah, sure. Happy to describe it. ~Um, so.~ Yeah, kinda initially the way we thought about Forget, ~um,~ and ~the, we, we have this, uh,~ in case you're not familiar, ~we have this, uh,~ we came up, I think it was ~kind of~ Sebastian, who came up with this idea of, ~um,~ puns for [00:06:00] projects that start with f ~uh,~ started with f with fiber.

~Uh,~ and it ~kind of ~has continued. ~Um,~ and, ~um,~ Yeah. ~Uh,~ and so forget the idea is that you can just forget about memorizing code. ~You can just,~ you can just forget about that ~as, as a,~ as a thing in, in react. ~Um,~ or at least that's one of the puns. There's probably others, ~um,~ like you can forget about the project cuz it'll never succeed.

~Uh, you know,~ like ~people,~ people like to come up with all kinds of variants.~ Um,~ but, ~uh,~ in any case, ~um, Uh, so, uh,~ so it started off ~as,~ as really auto memorization where we thought about Okay. In, and ~when you,~ when you write, react, the kind of mental model is that ~you,~ you re-render components, ~um,~ and their props flow down to children and the, those children re-render.

Right? ~Uh,~ and so ~kind of~ conceptually you're re rendering the tree kind of all the way from top, conceptually, from top to bottom. ~Every,~ every time there's any kind of, ~any,~ any. ~Uh, ~and then, ~you know,~ react has a bunch of optimizations within that. And one of the things ~that the,~ that the user can do is ~to,~ to add manual memorization.

So using, ~um, uh, you know, uh,~ react dot memo, ~uh,~ or, ~uh,~ in, in, ~in the,~ in the old days, ~uh,~ should component update, right? ~Um,~ react pure component. So there's ~kind of~ variations of this. ~Uh,~ and then of course, within a component you can use, ~uh,~ use. And use callback. ~Uh,~ and the idea there is you can ~kind of~ figure out, okay, where, [00:07:00] you know, where are my updates actually flowing and which parts like really unaffected.

And if you ~kind of~ add memorization that sort of constrains ~the, the,~ the update to the actual path that matters, right? You have some value that's like flowing from here, like from. One component down to one particular leaf, and you can just ~kind of~ avoid all the other paths along the way. ~Uh, and,~ and this works really, ~you know,~ reliably, you can use dev like dev tools to figure out which components should have some memorization added.

Go add that, and now you're gonna, ~you know,~ you're gonna get, ~uh,~ pretty good update performance. But there, there is that manual component. You do have to actually pay attention to adding that memorization logic, figuring out like when, ~um, you know,~ as your component of like changes over time, make sure to keep that memorization logic correct.

Right. So if you have ~like~ some new property, you have to make sure that you're checking for it or else you can, maybe your component won't update. Things like that. ~Um,~ and so the idea was, okay, the memorization is. Really more of an implementation detail. Like it's not the thing that you shouldn't have to ideally think about that.

What we want is for react to just be automatically reactive. It should just, [00:08:00] when data changes react your com, ~your,~ your UI should just react to that automatically. ~Um, Uh,~ and so the idea forget is that we, ~um,~ yeah, again, like ~kind of~ initially thought about it is just really getting rid of the, ~um,~ getting rid of the need to write, use memo or reactive memo manually.

And over time we ~kind of~ realized it's really about ~this, like r.~ The reactivity model that we want developers to think about. I have a value when it changes all the places that it's used will just automatically update, right? ~Um, and what that means is like un ~but un unfortunately in JavaScript, ~uh,~ if you create a new array, every single in, every single render, That is a new array, right?

Two, two empty arrays are not JavaScript does not consider them equivalent. ~Uh,~ and so react ~if you,~ if you do that, react will ~sort of~ overreact and say, ah, this is a new array. I must, I must redo my rendering because you've given me a new value. ~Uh,~ and so the idea is ~kind of,~ think about it as an auto reactivity compiler, is to say, okay, let's, ~um,~ let's really understand like ~the,~ the semantics of JavaScript and make it so that your components.

When they should and not more than they should. ~Um, and,~ and so that's, [00:09:00] that, that's ~kind of~ how we think about it. And of course the implementation of that is memorization. Yes. But conceptually, it really is more about reactivity, ~uh, and,~ and reacting only and like as much ~as, as,~ as, as close as we can get to like exactly when and only when it we need to you

Paige: I remember when I was reading through the article, it said when values meaningfully change instead of just values have changed. Like you said, it's the same array, but it's just been recreated because the rerender function has run. ~So, yeah. And you also,~ you touched on it a little bit already, but. ~You know,~ give us some more examples of how React can be too reactive, because I think we've all gotten stuck in those infinite loops before and use effect.

We've gotten, we've re-render, we've watched the same effects happen multiple times and wondered why, because nothing really has changed on the page.

Joe: Right. Yeah. Yeah. So ~I think,~ I think ~the,~ the most common one is, ~um,~ is things like creating, creating a new value. Like that you're creating a, you're calling a function that returns a new object. You're calling a hook that returns a new object. Cuz ~the,~ the hook probably should have had internally ~used,~ used memo, but it didn't.

And so now you're getting a new value and so you're just [00:10:00] accidentally creating new values. And then those of course, like, like you said, those can flow in as a dependency to a use effect. ~Right.~ And then that triggers and ~if,~ if that use effect is doing a set state or something. ~Um, and so,~ so I think some of the, some of what we touched on with like the use effect ~and,~ and infinite loops can happen because, Using an effect and setting state.

And there may be, I think there can often be other patterns there. The new docs really touch on, you have, there's a whole section you might not need an effect, which is, I, I definitely would like, ~uh,~ send people to, if you're having issues with effects, definitely read ~the new,~ the new guide, uh, around effects.

Cause I think ~it talk,~ Dan, ~um, and the,~ and the others who worked on docs like, ~uh,~ did a great job of really talking through the kind of patterns that effects are for and really how to think about modeling. But yeah, definitely. ~Uh,~ it's really almost anything in JavaScript. Any function call, including hook calls can introduce a new value, and that just Right.

~Has,~ has some side effects. ~Yeah.~

Paige: So what are some of the common misconceptions that people might have about React, forget, and this might be because you started going in one direction and then have since changed based on learnings or just, it's just not well known yet.

Joe: ~Um, yeah. Satia, do, do you wanna talk about this~

Sathya: ~Uh, yeah, I can, I can take this. Um,~ [00:11:00] maybe this is a good time to ~like,~ give a bit of, ~um,~ insight on this. History of like how the project has evolved. ~Um, right.~ Like I think, ~um,~ initially it was just a prototype with ~like~ a babble transformation that. Worked on the a s d and added like, ~uh,~ memo calls. ~Um,~ and then, ~um,~ we ~sort of~ rewrote that to be a little more complex.

~Um,~ and then we tried rolling that out, ~um,~ in our code base here at Facebook. And, ~uh,~ we run into a bunch of issues. ~Um,~ like for example, it wouldn't be able to do fine grain, ~um,~ memorization. ~Um,~ that's something that we thought was important. ~Um,~ so we ended up rewriting it again.~ Um,~ this time we ended up doing a way more,~ like,~ more sophisticated static analysis, ~um,~ on it.

So ~we,~ we ended up not having just an ASD level, ~um,~ ir, but ~like,~ like something that is like a control photograph. ~Um,~ and then, ~um,~ and then have that, ~um,~ have all the analysis run on that. ~And then we,~ and then we like. ~The,~ the interesting bit is like we compile back to JavaScript then, and then we try very hard to like, keep the same structure as the input code, so it doesn't look [00:12:00] very different, ~um, from,~ from the original source.

~Um,~

Joe: it doesn't get too much bigger than the original, you know?~ Yeah.~

Sathya: ~Um,~ so I think ~that's,~ that's ~kind of~ like one of the interesting bits is like most of the common like transformation, ~um,~ tools in the JS ecosystem work on the ASD level, and they don't really work on ~like~ the ~um,~ IR level, like the photograph level. ~Um,~ so I think ~that's,~ that's ~kind of~ interesting that, ~um,~ most folks haven't really thought about.

~Um,~ when we talk about forget, ~um,~ I guess the other bit is like, how. Understanding and ~like, um,~ or thought on what Forget is, has evolved. Like one thing is the auto reactivity bit, ~uh,~ that Joe touched upon the other bit is~ like,~ as we teach, forget about React, it ~sort of ~becomes this semantic analysis platform for react.

So you can, it can do way more things than just reactivity. ~Um, like,~ like for example, it can, ~like,~ you no longer have to ~like~ think about, say dependencies. ~It can,~ it can automatically compile that in for you. ~Um,~ and then ~you can,~ you can add way more lin, ~um,~ so that it's like you have [00:13:00] like a nice react assistant in your IDE that gives you hints and lin when, when you write some code ~that~ that is not idiomatic react. So that's ~kind of~ how, ~um,~ our thing has evolved. What Forget

Joe: Yeah. And like some of those are ideas that we're still working on, right? ~Like, like, like~ initially we, ~like we~ are focused on, and I think ~in my,~ in my head ~kind of~ forget is the auto memorization piece, and that's the part that comes first. ~Um,~ and like some of those pieces like ~the,~ the kind of the I, the I, ~um,~ improved Lin rules maybe doing automatic, ~um,~ dependency arrays for use effect, ~um,~ or use layout effect.

Those ~are,~ are ~kind of~ more like in the React compiler. Vain, which will like maybe ~come, ~come as like future features, but yeah, it's definitely more of a platform.

Paige: So do you see React? Forget taking the place of use memo and use callback and having to set your own dependency arrays like in the future when it's implemented, will you not have to use those hooks anymore or think about what you should put in your dependency array for use effect.

Joe: Yeah, so I think that, that for the dependency array for use effect, it's [00:14:00] probably, it's like a little bit different. ~Um,~ there are still some cases right now where, ~um,~ you, you do need to ~kind of ~manually specify,~ uh,~ a dependency array just because of, ~um,~ like there's like variables you don't want to react to.

And it's ~kind of, uh,~ and we're working on a new API use use effect event, which were, which is ~kind of~ meant for that case.

Paige: Mm-hmm.

Joe: ~Uh,~ but ~um,~ as far as use memo and use callback, yeah. The idea is that those sh well and, and and also react out memo that those may disappear as concepts of like completely, ~um,~ still T b d if, ~like,~ if they'll a hundred percent disappear, or if it'll just be that something you almost, ~that you,~ that you ~kind of~ rarely have to think about.

But certainly the, the idea is that for the most part, you'll just write code. Let forget, memorize it, and ~kind of~ move on with your day.

Paige: Yeah, a, a general developer who's doing something that's pretty standard, would never have to think about it. Maybe if you're doing a library or some really special use case, you might need to do it yourself, but generally you shouldn't have to think about it.

Joe: Yeah, exactly. Yeah. And, and the interesting thing there is, ~um,~ we've seen, ~you know,~ so we're ~kind of~ working on some product integrations right now, ~uh,~ and we're, ~you know,~ looking at code that already had existing used [00:15:00] memos. ~Um,~ and what we're finding is, ~well,~ actually these used memos, ~I mean,~ there's something wrong with them, but they're like very core screened, like creating a big array where like most of the values depend upon just ~like,~ like ~some,~ some variable x, let's say.

And only a couple of them depend upon. ~Uh,~ but the whole ha memo used memo block has to be really evaluated. If why changes and ~like, well actually,~ so we actually, ~uh,~ taught forget to ~like,~ rip apart the used memo in line, the callback, and then re ~like~ compile it itself, right? Because we can act like the compiler can do better than what the author did, right?

~Um, and so, yeah, I think.~ And again, ~like,~ maybe that's ~like~ an overly, like we might actually wanna like tune the heuristics for exactly how much we memorize, and so we might end up like leaving what it was. ~Um,~ but ~it's,~ it's really interesting that the compiler can just ~like~ be pedantic ~and,~ and ~like, uh,~ and like detail-oriented way more than any like human developer would be.

Right. And get like ~very,~ very fine grained memorization and reactivity. ~Um,~ so it. That we're still kinda like seeing exactly what that turns into in terms of runtime performance, ~uh,~ but it's just really interesting, like no human would wanna write the code that forget writes.[00:16:00] 

Paige: ~Well, it's,~ it's so interesting that you mentioned that because that is one of the things that I was ~kind of~ equating when you were talking about having a more fine grained approach to. What needs to be re rendered versus not, because signals has become a thing that has come back into the JavaScript consciousness, I guess is the best way to, to talk about it.

And ~you know,~ solid JS ~is,~ is a really good example of that. They talk really, they talk a lot about how they are all about fine grained reactivity and only updating the variables that need to be updated. So was that something that influenced. This creation of Forget ~was,~ was, forget something that you were already thinking about because you just had experience with how React works today.

Like ~how does,~ how does Signals fall into ~your,~ your way of building it or thinking about it or approaching it?

Joe: Yeah, ~well ~certainly we've been thinking about forget for quite a long time. The idea has been around, ~um,~ in kind of various forms. ~So, uh, you know,~ going all the way back to the creation of hooks, like really came out of some explorations with, ~um,~ prepack, which is ~kind of~ an earlier attempt to [00:17:00] build a kind of a compiler.

For React, ~uh,~ and the realization that class-based components are ~kind of~ just a class instance is like a, just a big. Mutable ball, like, you know, bag of mutable state, right? ~Um,~ and so how do, how does a compiler understand anything about that when you know the value this, like whenever it appears, that's mutability that just ~sort of~ spread across the whole spectrum and there's all these lifecycle methods.

~Um,~ and so hooks are a, a, a way clearer, ~uh,~ target for a compiler. ~Um,~ and ~so,~ yeah, ~like, you know,~ going back years really like ~the,~ the idea of for Forget was there and it was a matter. Figuring out~ how it,~ how it should work, finding somebody to~ kind of, you know,~ actually just prioritizing the project itself.

Like we'd already tried to compile or hadn't worked out, so we kinda had to like, take care of a bunch of other things We were working on, ~um,~ the big, ~uh,~ fiber refactor, right? ~Uh,~ so this is like ~the,~ the concurrent features ~and,~ and suspense. ~Um,~ and ~so, uh,~ yeah, the idea's gonna ~really, really,~ really been there for a long time.

~Um, I dunno. Satia, do you wanna touch on signals?~

Sathya: ~Um, yeah, but before,~ I want to add on to that where~ like,~ it's not just hooks, but. The React paradigm itself is, is so good for a compiler, right? Like the, the idea of like having a [00:18:00] pure decorative ui, ~um,~ and just having a pure function, ~um,~ render function, ~that's,~ that's really great. ~Um,~ because a compiler can reason about it really easily.

~Um,~ whereas with to ~like,~ I impressive code, it's ~like,~ it is way harder ~just,~ just like it is for a human right. ~Um,~ so I think. Plus hooks kind of unlocked. Forget, ~uh, that's,~ that's ~kind of~ how I see it. ~Um, but,~ but yeah, like compared to like signals, I think the mental model of, ~um,~ forget O of React is mostly working with values, right?

Like I think ~we,~ we sort of like that and we want to keep. Keep that working model. ~Um,~ so I think what Forget, we will let React post, write the React code they like and they're used to writing. ~Um, and,~ and now we have ~like~ a platform where we can add in reactivity and who knows, ~like, right,~ like later we might add signals as like an implementation detail and it just compiles in the signals, ~um,~ could into the component.

~Um,~ so yeah, we. I don't think we're like, settled on, ~um,~ something to do with like [00:19:00] signals yet. We're still, ~um,~ it's still, ~um,~ something we're thinking about.

Joe: ~Yeah, and I mean, I, I just also wanna call out like, uh, it, it,~ it has been great to see the different, like the, ~like, you know,~ different, ~uh,~ libraries like solid, ~um,~ and others who are exploring, exploring signals. ~Um,~ Like we, we love the fact that there's like other approaches in the ecosystem being explored.

I think like competition is just good for everyone across the board. ~So, um,~ yeah, solid in particular, ~uh,~ just I think it's really, really well done. ~Um,~ but yeah, we definitely, ~you know, we, we,~ we like the React program model. ~We,~ we do think ~like, kind of~ working with plain values, being able to ~kind of,~ oh, this values, no, let me return, just return ~like, you know, ~return like a placeholder and just not.

It's a function. It ~kind of~ works more ~like, uh,~ you, you expect. The reality is that. Everything in this space is ~kind of~ like somewhat abusing JavaScript, semantics, ~like, um,~ like SVE is like overloading assignment. ~Um, you know,~ react is like, you know, react, forget is like making it so that code that like you think would run just literally doesn't run again.

~Um, you know,~ solid is, is rewriting the jsx in your components ~and,~ and also ~like, what, what,~ what, ~you know,~ coming from a React background, you think this function's gonna run again. It only ruins once, ~like,~ so they're [00:20:00] all like slightly, ~you know,~ tweaking JavaScript semantics in a way. ~Um,~ but ~like,~ I think, ~you know, we're,~ we're biased.

We think that the React way feels a bit more javascripty, right? ~Um, and,~ and so we want to ~kind of~ preserve that and, but ~like~ Satya said, like signals, maybe it's an implementation detail of forget down the road, but, ~um,~ but with the same programming model that you have,

Paige: Yeah, and ~I mean,~ when you look at the JavaScript language in general, there've always been a couple of really curious design decisions that they made, and we've just all learned to live with it and work around it

Joe: ~Oh yeah.~ Oh yeah. ~We,~ we definitely know since we've been writing a compiler, there's, we're like, what? What? Why does it work that way? It's interesting. ~Uh, yeah.~

Paige: ~Um,~ okay, so one question that I had and that one of my friends asked was, ~how, how can,~ is there a way for devs to get started with this right now? ~Like, is,~ is there some beta version of React forget that we can use? Or is it still ~kind of~ an internal thing? And what kind of potential patterns could developers start working with that would make their code more or less compatible with it in the future?

Sathya: ~Mm-hmm. ~

Joe: ~Satya.~ 

Sathya: it's, yeah. I think the second part is like ~the,~ the [00:21:00] interesting question for me, ~uh,~ which is, ~um,~ like code that follows the rules of H Hooks, the rules of, ~uh,~ react basically, and. If you don't have any, ~um,~ disabled es exhaustive depths, ~um,~ comments on your render function, then I think forget should work fine now.

~Um,~ so I think what we've followed while building forget is, ~um,~ if you're writing idiomatic record, then you're. Once you're running, ~um,~ and using escape patches, then forget, might not work out of the box. ~Um,~ that, that's ~kind of our,~ our philosophy while building forget. ~Um,~ as far as like trying to run it right now, I think it's still, we're still, ~um,~ productionizing it, ~um,~ mental only.

And then I guess once we have, ~uh,~ more, ~uh,~ data and conference, we can start thinking about rolling it out to open source.

Joe: Yes. And ~like,~ just to, to build on that, like examples are, ~you know,~ use Effect is like a, a kind of an [00:22:00] approved, official public API for, ~you know, um,~ interfacing with external systems. So ~like,~ forget works there. The things that are problematic are things like, ~um,~ passing like a dyna, like a hook or passing a, ~uh,~ calling a component as a regular function for, ~uh,~ actually ~is,~ is like a perfect example.

~Um,~ where, you know, the idea with a component is that you're meant to use J S X syntax to invoke, its that react can laly ~kind of~ evaluate that component inside of its own kind of ~like, uh,~ component.

Paige: Right.

Joe: But ~if you,~ if you violate that, ~well~ now that code is ~kind of~ running in like a weird way. And if you call a component as a function that you can call it anywhere, the hooks inside that can be called conditionally.

~Uh,~ and so that can ~kind of~ wreck havoc on, on the compiler. ~So, you know, like,~ but, and there are lint rules to prevent you from doing this, ~but you know,~ so you like, so that's an example of ~like~ if you're writing idiomatic React and just following the rules and rendering components as J S X, things are fine.

If you break that, ~things will,~ things will break. ~Um,~ using refs, right refs. The complete escape hatch. ~Uh,~ and so as you start using refs in particular, refs are fine when you use them fine ish. ~You know,~ like obviously ~there's, there's often,~ there's often [00:23:00] reasons, often, ~uh, um, you know,~ better patterns ~where,~ where you don't need a ref.

But ~when you do,~ when you do actually need one, that's fine. ~Um,~ but ~the, the, the, the,~ the problem is, ~um,~ accessing the reps value during render, right? ~Uh,~ the reps are ~kind of ~meant to be like really used in effects, right? But ~if you,~ if you access them during render, then that can, cause that's basically mutable state, ~uh,~ that forget doesn't really know about or understand the lifetime of.

And so it can't react. And so an example of a problem we've seen there is, ~um,~ we had a, where there was a, a component internally that was like, I forget exactly what it was doing, but ~it,~ it was. Looking at a ref, ~uh,~ and just ~like, kind of like~ rendering the result value and somehow relying upon the parent component to re-render and in some way like update that ref.

~Um,~ I think it was like, In a, ~like,~ anyway, and, but the point is that if we now minimize that component and don't render the parent again, ~well~ now ~the,~ the child doesn't update. And so ~the,~ the thing there is~ like, well~ just use state, like the, there is, ~that is,~ that is inherently state, right? ~Like, um,~ so just use the built-in mechanism to do that and then, and then forget what work just fine.

~Um,~ and [00:24:00] so, We have lint rules for all these things. We understand, ~like, you know,~ there's times where developers are just trying to get stuff done, they bypass the lint rule. ~Um,~ but if, ~you know,~ if you're trying to get ready for, forget and want to, and like ~kind of~ roll that out more, ~um,~ then, ~you know,~ like paying attention to those lint rules is important.

Paige: ~Okay.~ Fair enough. ~Um,~ so ~I mean,~ we've talked a little bit about what this means for the future of React and ~kind of~ where it's going. Is there anything else that we haven't really discussed yet that you wanna touch on in terms of React, forget and the compiler?

Joe: ~Yeah, I think there's like the, the kind of DevX piece that we were talking about, Satya.~

Sathya: ~Um, you mean like the compiling and the difference area?~

Joe: ~Well, I think, I think, um, yeah, I think so.~ One of the things we've that, yeah, Satya touched on this earlier, like that kind of IDE integration, ~um, kind of~ giving more feedback to the developer as they're working, ~um,~ that they're, ~you know, the,~ the existing lint rules ~are,~ are very like, are very comprehensive.

Forget is even better and more sophisticated in, it's, in its analysis. And so I think it can do even more. ~Um,~ So we still have to ~kind of, uh,~ actually ~like~ build all that out, like kind of forgets doing its own its analysis internally, but we're not, that's not hooked up to the lint rule yet. But I think~ kind of ~long term ~what,~ what we foresee is ~like,~ almost like a, ~uh,~ a React ide like kind of language server, ~you know, uh,~ plugin, ~um,~ that can be ~kind of~ giving you like [00:25:00] specific hints like, ~uh, you know, Maybe,~ maybe showing you, ~um,~ this value is like not as~ like,~ efficiently memorized as it could be because you've done something and maybe here's a hint for how you can structure your code better.

~Um, right.~ We have all this knowledge that like we can surface to the developer to help them write better code. ~Um, uh, And,~ and that could also go into ~like~ helping to understand like, ~you know,~ maybe even understand like exactly what ref pat, what weird ref pattern you're doing, and suggest a specific, ~you know, like,~ oh, okay, it looks like you're doing this pattern.

Maybe go see ~this,~ this, ~you know,~ this documentation page for, ~uh,~ another way to think about this, right? So I think there's a lot of opportunity there to ~kind of~ use our sophisticated understanding of the code to help the developer learn to ~like~ get their work done. ~Um,~ yeah, ~so.~ An area that ~we're,~ we're really excited about exploring, but ~uh,~ first we gotta ship memorization.

Paige: Right. So it's ~kind of~ react co-pilot light, is what you're saying.

Joe: Yeah. Something like that. Yeah. Yeah, exactly.

Paige: Nice. ~Well,~ I wanted to touch on a few of the other things that you talked about in the newsletter, just because we have some listener questions that are around them, and I'm sure that people would love a high overview. So one of the other things that we talked about a little bit towards the beginning and now [00:26:00] again, is the react server components.

~Um, and one person,~ one listener, wanted to know, How are they going to improve the development of full Stack React applications, which I think you talked about ~it's~ it's server side rendering first class, but maybe you wanna talk a little bit more about that.

Joe: Yeah. Yeah. ~Um, so.~ I think, ~you know, a~ a lot of folks have asked us how should they do data fetching in React?~ Um,~ how should they do routing in React? ~Um,~ the routing, ~there's,~ there's, ~uh,~ long been ~a great,~ a great answer, which is React Router has always been a, a, a ~really,~ really, ~um,~ amazing library.

~Um, and, you know, we've, we've always recommended,~ we've long recommended that we use that. ~Um,~ but, ~uh,~ the data fetching side has been more of an open question, ~uh,~ and in particular there. Even if you have a good routing solution, you really want them, the data fetching and routing to be integrated. This is something I think we, we've realized internally, ~uh,~ all the way back, like when I joined, ~you know,~ Facebook back in 2014, this is like ~the,~ the u the insight for me is ~like,~ oh, wow.

Yes. ~Like they were like the, the,~ the precursor of the re it's a relay team was integrating data fetching and routing and like all the things that, that unlocked way back then. ~Um,~ but ~the,~ the challenge has been figuring out how to ~kind of~ make [00:27:00] that. General purpose, capability that everyone can use, right?

Like we were doing that with GraphQL, which is like a way to let us, ~um, kind of~ take all the data dependencies of the UI and ~kind of like~ bubble them up. To the route level so that we could then do a route level, say, okay, we're going to this route, let's get all the data for it and render it. ~Um,~ and so there hasn't been a great kind of general purpose way to do that.

~Um,~ remix loaders are a, like ~a, a,~ a pretty good solution for this. But, ~um, you know, it's,~ it's still. Like for each nested portion of your route, you've still got a lot of components there and you're like, what do you, how do you like aggregate all the data fetching for them? Server components are ~kind of ~go one step further and say, yeah, just let individual components fetch the data they need.

And sure, for the client portion of your app, you're still gonna have to ~kind of~ fetch everything that they, ~that~ that client portion needs on the server and kind of pass it down. But it makes it much more clear how you could structure a whole app. ~Um,~ and I think similar to the kind of the way that rem.

Apps can often not need really too much client kind of state management solution. You get that same thing ~with,~ with [00:28:00] a, with the kind of server components outta the box. But again, like ~where,~ where you have true co-location of data dependencies in the exact component. And I think that's, it's something where it's ~like,~ oh, that sounds nice, but ~like~ as your app gets bigger, it ~really,~ really matters to be able to just say, oh, I need this extra, like this extra piece of information.

I will just fetch it here. I don't need it anymore. Cool. I'll stop fetching it. And nothing else in the app breaks because, ~you know,~ all your data fetching is local. ~Uh,~ it's just so power.

Paige: another question that kind of ties in well is ~when,~ when should we use a server versus a client component? ~Like is there,~ are there any. Easy, easily recognizable things that you can say, oh, if it's this kind of a situation, it only needs to be on the server or it should be on the.

Joe: Yeah. So I think, as a general rule, I think of it, I think of it as your app starts with a server component route. ~If you're kind of,~ again, and ~this is,~ this is very much ~kind of,~ if you're building a brand new app today, ~how,~ how would you structure it? Certainly there's ~kind of ~incremental migration considerations that we can talk about, but, ~um, you know, kind of.~

In a, in the kind of, in the future paradigm, [00:29:00] right? The server components paradigm. You're ~sort of~ starting with server components at the root, and you basically stay in server components until you realize, oh, I have some interactivity. ~Uh,~ and that's when you can, that's when you introduce a client component.

~Um,~ but the interesting thing is that, ~um,~ We don't allow client components to render server components. Could that, because that could cause a waterfall and have to go back to the server, ~uh,~ to make another request. But you can ~kind of ~structure, there's like the pattern of, ~uh,~ passing children into a component.

So for example, you can have a client side, ~uh,~ tab component. Where the actual tabs themselves are all chil, ~you know,~ our children passed from the parent and they can be all, ~be, be,~ be actually server rendered. So you can have ~like~ the server page that's saying, okay, I'm gonna render a tab component and pass in a bunch of server rendered, ~uh,~ children to it.

And now the client is simply just choosing between pre-rendered, like which pre-rendered tab from the server. So those kind of patterns work too. So you can think about ~kind of~ designing your interactive components in that way to allow that server content to still be passed in. And then that kind of gets it so that it's really [00:30:00] just the interactive pieces, ~um, that~ that end up actually being client component.

Paige: ~Nice. Okay, so let's, let's move on.~ Another thing that you touched on is asset loading. ~Um, ~and this actually brought up a question that you already ~kind of~ talked about, which is, ~you know,~ react Router has been ~kind of~ the default ~for~ in terms of routing and. Uploading different pages and stuff like that.

But one of ~our,~ our listeners wanted to know, is there gonna be something that you're going to include in the React core for data manipulation? ~You know,~ Redux has been a standard for years. React Query has really come into its own recently. So is there something like ~that~ that react overseas being part of its core?

Joe: Yeah, that's a great question. ~Um,~ we've thought a lot about what a, ~like, what,~ what is the sort of, ~uh,~ state management primitive that should exist and react? ~Uh, we've, yeah, lots of,~ lots of discussions. ~Uh,~ lots of kind of prototypes and ideas. ~Um,~ I think what we've ~kind of~ come to, at least ~for,~ for right now is that really like server components and ~the, the,~ the fetch and cash APIs that are kind of part of server components, ~um,~ are.

Really, actually a lot of that, like ~the,~ the, for example, ~so, um,~ just [00:31:00] using the built, like the built-in fetch mechanism in a server component, that, that actually is a state management system. Especially when, when you ~kind of~ combine that ~with the,~ with the, the sort of caching and the routing integration that happens in next, for example, and other framers can implement similar patterns.

~Um,~ so specifically what I mean there is, ~you know, you,~ you. Go to some page. It's most all, it's mostly surrendered. You do some action that goes back to the server, re refreshes the server content that comes back down and the the page updates. And there's no state management, there's no client side state management ~at the, at the,~ at the application level happening there.

It's just kind of part of the framework ~that~ that content refreshes ~as,~ as the action occurs. And now, ~you know,~ you navigate other pages that were cashed and we know that well, there's been a mutation, so we can ~kind of, uh,~ invalidate those CAEs and re fetch them ~as you,~ as you navigate around again. ~Um,~ and you're basically getting. ~Or,~ or you could do Sta or, or they could do stale ~Well~ and validate. ~Right, right. Like,~ and a lot of those things just, ~uh,~ or even the need for something like React Query, that's a great library, but the need for it might go away. You might not need that as much, ~um,~ because you're just using a server component.

You might still use that library and, ~you know,~ relay, [00:32:00] react, query all, ~uh,~ Apollo, like all these data fetching libraries, redux, they might still make sense for the client portions of your app, but for a lot of the. ~You know,~ server commands will actually, ~uh, you know, just,~ just work. So we'll ~kind of~ see how things go.

Paige: ~I mean,~ that would be awesome because we always wanna ship less JavaScript and have less, less sizable bundles and less libraries. So if, if React can handle that. So do you see that affecting the future of the Context api or does that still have its own, ~you know,~ unique use case?

Joe: ~Um,~ yeah, I think ~like~ the context api, ~uh,~ as far as we're thinking now, still, ~you know, a,~ a core part of React, ~um,~ There's just a lot of use cases for that sort of within this subry. ~Some, some,~ some, ~like,~ some value is true or, ~you know,~ like ~a, ~a, a theme. ~Um, yeah, just,~ just so many interesting cases where that, ~where, where,~ where ~like~ that's just can be solved by context.

But yeah, we'll definitely still evaluate. we're ~kind of always,~ always rethinking, ~uh,~ our own best practices. ~So,~ but yeah, certainly, ~uh,~ for now, like we, we see context as ~a,~ a part of.

Paige: All right. ~Um,~ so can you tell us anything about either [00:33:00] the document metadata or the offscreen rendering, both of which were also mentioned in the blog post?

Joe: Yeah. ~So, uh,~ I can touch on them briefly. ~Um,~ I think one of. Kind of meta point here is, is actually that, ~um,~ the React core team has grown in size quite a bit. ~Um,~ and ~so, you know, uh,~ a few, a couple years ago, it really was a small team where I think everyone had much more context on everything that was happening.

And one of the interesting thing that's happened over the last couple years is we've significantly increased the number of contributors across the React, ~you know,~ across the React core team and the react space. ~So, um, So, uh,~ Josh story and ~with a, ~with ~a,~ a little bit of help from, ~uh,~ from Mofei , ~um, and,~ and as well as o o obviously many others, ~uh,~ are working, but primarily Josh is, ~uh,~ working on, ~uh,~ what we call float, another, uh, f, uh, pun, pun name.

~Um,~ but, ~uh,~ it's kind of all really about, ~um,~ setting things like document metadata, ~uh,~ like being able to preload a C s s and, and other, ~uh,~ assets. ~Um,~ and so ~the,~ the blog post goes into more detail, but really the idea is, What are the missing pieces so that to, to let react really own the whole document as opposed to just rendering [00:34:00] into, ~uh,~ a piece of that.

And, ~um,~ and then with within that, there's ~the,~ the kind of challenge of. You really want to allow, we really wanna allow, ~um,~ components to be fully modular. ~So,~ and, but things like link tags that go, ~you know,~ it's this component needs this link tag to be on the page, but the link tag has to go somewhere else.

And so how do we make that work? ~Um,~ but while still allowing you to think about component as like the unit of encapsulation.

Paige: Mm.

Joe: And then offscreen rendering. ~Um,~ so Offscreen Rendering is a project that, ~uh,~ on our side, actually some, ~um,~ so Sam, ~um,~ Sam Sola, who's on the, like traditionally who's on the React native team, has been contributing a lot.

So again, like just really increasing the number of contributors to the kind of core react effort. ~Um, uh,~ so he's been working with, ~uh,~ Andrew Clark on this. And, ~uh,~ the idea is to take advantage of our new concurrent rendering capabilities to say, ~uh,~ let's,~ you know,~ be able to start rendering content.

That's, that's like not even visible yet. And ~kind of~ treated as offscreen. ~Uh,~ and so this can work for things like pre rendering, ~uh, ~a, a route that like, ~you know,~ you hover over a link. Can we start pre rendering that? ~Um,~ you have a virtual [00:35:00] scroll list? Can we start pre rendering items that are about to appear?

And then also as items go out of, ~you know,~ out of view, can we ~kind of, um,~ put them into the, this offscreen state, which is using less resources, right? We don't need all their subscriptions to be firing. We just ~kind of ~need, like, when it comes back into view, we can just refresh it, for example. ~Uh,~ and so that's the idea of offscreen.

But, ~uh, still,~ still in the ~like, um, exploration phase or in the~ implementation phase, ~sorry. Um,~ but yeah, I think, ~uh,~ definitely promising.

Paige: ~Well, that's,~ that's actually a great segue as you're talking about what is coming next. So are there any other features that you can share about React or to our listeners that things they can be looking out for, things that are coming soon, things that, ~you know,~ you've started potentially playing around with or thinking about adding to it.

Joe: Yeah, I think the main thing I would call out is, ~you know,~ we've gotten a lot of feedback from the community around the usability and developer experience with hooks, right? ~Um,~ we, ~you know, you,~ you touched on that earlier, ~uh,~ talking about some of the issues with ~like, um, you know,~ manually specifying dependency arrays for use effect.

~Uh,~ and, ~uh,~ there's a few other kind of, ~um,~ more like somewhat more niche use cases around refs, ~um,~ around use effect. ~Uh,~ and so we're ~kind of~ exploring. Some new APIs that [00:36:00] kind of helped to really fill in the kind of, ~uh,~ few kind of gaps and around ~the,~ the usability ~of,~ of those hooks. ~Um,~ so for example, ~uh,~ one thing that we were looking at was ~can,~ can reps have like a cleanup function?

~Um,~ so use effect, the kind of,~ um,~ Right now we just have this sort of create and destroy semantic, but sometimes you actually want to have something that gets preserved and just updated. And so you want more like crud, semantics, like create, update the effect as it changes and then destroy. And so can we support that use case?

~Uh,~ and then also, ~um,~ I mentioned use effect event, which is ~kind of~ targeted at these effects that. Want to update when certain properties change, but not others. ~Um,~ and so making that more of a first class concept. So these are things that we just, we've heard the feedback from the community. ~Um,~ Dan Abramov was, ~um,~ as he was writing the docs and coming up with examples, like, did a lot, a lot of research and helped identify these, these pieces ~and,~ and ~kind of~ formalized them into APIs.

~Uh,~ and ~so,~ yeah, I think that's something that I'd be on the lookout for. ~Like, you know, there's,~ there's like the everyday things that you run into as a React developer that we wanna help make, ~you know,~ make better for people. ~Yep.~

Paige: ~Uh, okay.~ So what are you both excited about for 2023? And this could [00:37:00] be react related, it could be personally, it could be just completely out there. What are you looking forward to this year?

Sathya: I guess shipping, forget.

Paige: So that is the goal though, ~is,~ is to release it sometime in 2023 to the general.

Sathya: no promises, but yeah, we, we would, ~uh,~ like to ship it, ~um,~ and have everyone in the ecosystem use it. I think we're definitely listening to the community, ~um,~ hearing the pain points from them and we're trying to improve it.

Joe: ~Yeah.~

Sathya: ~So~ I think, ~uh,~ forget is a big piece of that puzzle.

Joe: ~Yeah.~

Sathya: I'm definitely excited to get this in the hands of react, develop.

Joe: Yeah, I think, ~uh,~ same. Really excited. It's been a super fun. I mean, it continues to be a super fun project. ~Um, uh,~ but yeah, it's, I don't wanna ~like~ get ahead of ourselves and the say,~ like,~ we're excited about the next thing. But there's like, I think ~am,~ I am really excited about ~kind of~ what comes next.

~Like the,~ the pieces that we talked about, like ~the,~ the kind of ID integration, ~um, you know,~ think rethinking. Okay. Today, we like the runtime works [00:38:00] in a certain way. Now that we have the sophisticated compiler, can we actually change what's happening at the runtime to take a, ~you know,~ to take advantage of that better?

Like whether it is signals or some other kind of, ~uh, other,~ other ideas, ~um,~ we've explored around ~like. You know,~ more targeted updates, ~uh,~ for things that like the compiler can unlock. ~Um, we've,~ we've ~like~ thought about things like, ~uh,~ server optimized bundles, right? Where like the compiler know if, like the compiler knows, like the semantics of use effect and can say, ah, I know that, right?

~Like,~ Can we produce an optimized bundle that not only strips out like your use like us, so for ~like,~ for server rendering builds, for example, can we like strip out the use effect and then do dead code elimination on all the values that were only produced to pass to the effect and then like further optimize up the tree and, and really~ like~ improve performance that way.

~Um, you know,~ these ideas may or may not pan out, but these are like, uh, interesting things that, ~you know,~ I'm looking forward to exploring. Again, though, we gotta like actually ship, forget.

Paige: Right. You gotta get what you're working on first done and then go on to the next

Joe: So really excited for that. Yes.

Paige: ~Nice. Well, this,~ that's actually a perfect segue into my last point. So Satya, you had a tweet that [00:39:00] was pretty interesting where you said that some people feel like react is winding down. ~Uh,~ obviously it seems like neither of you feel like that is the case, ~but you know, what are the,~ what are the new players doing for you?

~Are they,~ are they giving you more ideas, more fire to get to bring, react, ~you know,~ into what is the new and hot today like? What would you say to those people who feel like React is ~kind of~ in the past still and they're going for the new JavaScript frameworks?

Sathya: yeah, it's, ~that's,~ that's an interesting question. ~Um,~ yeah, I definitely don't think it's in the past and we're like innovating a lot on React actually with ~like~ the forget compiler. ~Um, so they.~ I'm definitely excited for the future of, ~uh,~ react. ~Um,~ especially like with Forget helping, ~um,~ on ~like~ the static analysis bit and then all of the capabilities we're unlocking with several components.

~Um,~ I think it's definitely an exciting time to be a react.

Joe: ~Yeah, totally.~ I think. ~You know, I think we, ~the, the work to build the concurrent rendering features and react like definitely took a, a long time to ~kind of, um, to just,~ to just work through the different, like all the different design, uh, and like kind of user experience like trade [00:40:00] offs, right? ~And we're,~ and we're ~kind of~ still tweaking the user experience pieces of that, but that's a fundamentally.

It's a fundamentally powerful capability to, to be able to render ~like~ a different version of the UI ~kind of~ in the background. ~Um,~ and so the fact that I think ~we've,~ we've invested in that, we've ~like~ brought the community along with this, ~like, you know,~ this, ~um,~ immutable, ~you know,~ style ~of,~ of writing code and I think we, we definitely hear the complaints of ~like,~ oh, it's so much easier just to write ~like, you know,~ mutation in place.

But it's so powerful what you get when you use the React style. ~Um,~ and I think, ~you know,~ it's features like offscreen, ~um,~ it's features like server, ~uh,~ server components, ~which, which really,~ which really do kinda depend upon a lot of ~the,~ the concurrent rendering features, ~uh,~ under the hood. ~Um,~ like ~the,~ the routing features.

~Um,~ maybe in the feature animations, again, no promises, ~you know, um,~ that ~like, uh,~ we, I think though, like as we're able to ship out, not just like ~the,~ the core. Concurrent features. ~Um,~ but like the things that kind of build on them, I think that's when people are gonna, ~like,~ a lot of things are gonna really click reveal, ~like,~ ah, okay, the React team saw this and invested years to get here.

Where other frameworks, yeah, ~like,~ okay, you can achieve like a simpler thing with a much simpler implementation. And ~that like, seems~ that's [00:41:00] nice and something wrong with that, but ~like,~ we think it's worth the investment, like ~the,~ the longer term investment to build ~like~ an even more powerful system that delivers, not because we can, but because it delivers ~like~ real tangible user experience benefits.

Paige: ~Yeah,~

Sathya: ~I think the other, sorry. Um, the,~ the one thing that ~we,~ we actually didn't really touch much on is like ~this,~ this entire like ecosystem of React native, which is also amazing, right? ~Like~ as a React developer, you get to be a mobile developer as well. ~Um,~ and that's something ~that's,~ that's an insane value add. From being a reactive.

Joe: ~Yeah.~

Paige: ~Yeah,~ I mean it, I love React just for the fact that it is, it has worked so hard to be backwards compatible while all always introducing these new features that make it so much easier to do the same things. ~So, you know,~ I, I understand getting it right the first time that you actually release it to the public is a big deal and having.

Having a legacy code base that you're also supporting at the same time and making sure that it still works ~is,~ is a massive undertaking. So ~I,~ I'm excited for the future of it and it has been an absolute pleasure to have you both on. Thank you so much [00:42:00] for joining us to talk about React compiler and all the cool new things that are coming to react in the near future.

Joe: Thank you so much, Paige. It's been pleasure.

Sathya: you for having us. ~Yeah, script.~

Paige: ~Is there anything else that you think that we should touch on before we sign off on today's?~

Joe: ~I think that, I think we covered a lot. Yeah. That was.~

Sathya: ~Yeah.~

Paige: ~Excellent. Well,~ once again, thanks for being on the Log Rocket podcast and we will see everybody for the next episode.

Joe: ~Thanks.~