Andrew: So, yes, my name is Andrew, I'm the React atom floating. Next time I think we'll make it so I have two phones so I can join from my account. Oh, there's Dan, let me add Dan. So this is our first time hosting a space. Well, I've done one before, but nothing like this. I have a feeling there's going to be a lot more people on this space than the silly spaces I've hosted before. So we might learn as we go along, but we we've gotten some great advice from some folks ahead of time the proper way to manage these things, including from Laurie, who I think we'll hear from later. So I think this is going to be really great. Hopefully the first of many.
Andrew: Let's just give it a few minutes for people to trickle in. I'm sure we'll have additional guests as we go along. Brian is giving us a reminder: if we do invite you on stage to please mute yourself when you're not speaking, I will do the same. We've got some great questions that we've collected in advance from members of the working group. And if you do have questions, you can either reply to the React tweet that we just tweeted, or you can DM Ricky directly. We might not get to every single question, but the goal of this is really so that we can try and hear from the community. So please send us whatever questions you have and we'll do our best to try and answer most of the questions that we see.
Andrew: Again, this is our first one. We might not get it right the first time. And so, Rick, I'm just going to answer here: you asked me to make you an admin. I don't think I can. I think I can just make you a speaker. Maybe we'll figure that out next time if that doesn't work. But yeah, as I said, learning as we go along, but let's get started, it's three minutes past the hour.
Andrew: So welcome! This is the React team's first Twitter Space. Hopefully the first of many. We've done Q&A's before, but never in this medium. The agenda for today, or the goal of today, is that we had an announcement earlier this week on our blog post. And we can talk about that, or we can talk about anything else that people ask questions about. We also have a special guests later in the show, which some of you already figured out, but I'm still going to tease it as if it's some large surprise. So that'll be exciting if you stay with us. We'll probably go for about an hour, no longer than that, we'll see how it goes. Maybe we'll end sooner, maybe we'll go a little bit later, but I think an hour is a good amount of time to be on the stream.
Andrew: Let's just dive straight into it. Like I said, though, if you do have questions, please tweet at the reactjs account or you can DM Ricky directly and he can field some questions. And if you would like to speak, actually, we might try that. Tell Rick about that in your DM. We'll see if that works. It would be nice, but again, we're new at this.
Andrew: Anyway, to get this started, I would actually like to have Ricky give us a summary of the blog posts that we published earlier this week. We published a blog post called The Plan for React 18. Could you give folks a summary of what we announced in that blog post, Rick?
Ricky: Yeah, for sure. So this is super exciting, we've started working on the React 18 release. React 18 is going to be the next major version of React. As part of that release, we have a gradual adoption strategy for some of the new features that are in React 18 , and to help prepare the community we've created a working group to discuss all the new features that are in it, and get everyone prepared to get on to 18, which is really exciting.
Ricky: We've also announced that we published our React 18 alpha, so that library authors can try it and get feedback. We want to be like pretty clear here that right now, at this point, if you're not a library maintainer or creating educational content, or really interested in getting far ahead, then there's nothing for you to take a look at today. You can safely ignore the release for now, but you're welcome to follow the discussions in the React 18 Working Group, if you're curious. Yeah, that's the release. It's very exciting stuff, and today we'll be answering questions about what we announced and what's in 18.
Andrew: Excellent. Thanks, Rick. So next I wanted to ask Christine to give us a few more details what is the React 18 Working Group? What is its mission, and maybe give some background there, Christine?
Christine: Hi, this is Christine, and I'm also excited to kind of get this kicked off! So the vision, when we put together the Working Group was we wanted a space again, as new features were being launched, starting with React 18, to bring the community in on discussing the new features. The goal, was to introduce library authors so that there's a place where they can discuss all the various features as we work towards it. And we also wanted a place where the whole community could also see these discussions. So we're looking at increased transparency to make sure that people could actually get a sense of what is going on. And that was one of the things that we wanted to improve on. And we also wanted to involve a small group so that it was manageable. So a representative set from the community. As I've been mentioned before, we're looking for library authors, educators, and also everyone else to be able to kind of like chime in and see what was going on. So that was basically the goal and the vision and the mission. So hopefully that actually kind of gives you a sense of what it is that we needed.
Andrew: Thanks so much, Christine, and also I forgot to intro you. Do you mind giving folks an introduction to who you are?
Christine: Yeah. Sorry about that. So my name is Christine and I am a developer advocate and I will be overseeing the React family of technologies and that includes React.
Andrew: Excellent. Yeah. And we're so excited to have you on our team and really appreciate all the work you've done in getting the working group set up. So next I wanted to ask Laurie a question. Do I see Laurie on the stream? Laurie, are you here? If you are, can you maybe request to speak? I don't see you on here. Let me just search for Laurie real quick. Oh, I see. There we go, Laurie. Excellent. sorry about that. So Laurie, I wanted to ask you since you helped us kind of create this space -- this Twitter space -- today. And you've been a really great member of the working group so far in the discussions we've been having in the, in the GitHub repo. What has been your impression about the working groups so far and how are you feeling about it overall?
Laurie: Yeah thanks. Hi everyone! Awesome to see this space! I think this is such a great use of this technology. Yeah, the working group has been really interesting so far. I think my original assumption was it was going to be a bunch of people sort of diving into really technical details about how all this stuff is implemented and making the core team explain a lot of that. But it's been so welcoming and there's been so many different levels of people asking questions about everything from, you know, terminology (how are we talking about this) to how can I use this? And what's the migration path and all of those things. And that's been really exciting to see. Particularly, I think people's level of excitement that there isn't really much of a migration path to work with React 18, and all of these features are opt in, which is a huge win for the community at large.
Andrew: Excellent. Thanks, Laurie. Next I wanted to talk to Cassidy. So Cassidy, I think I already approved you as a speaker, right? Is Cassidy there? Let me just make sure, sorry. I'm still getting used it.
Laurie: She's there, but she's not a speaker yet.
Andrew: Okay. I thought I had approved her. I could have sworn that I approved her on here. Oh, there I see you, sorry Cassidy, I'm still getting used to this UI. So yeah, Cassidy, the reason I want to invite you up to the stage is the working group was largely inspired by some great feedback received from you last summer about the React team's communication and what we might do better to engage with the community more. We really appreciated that feedback and it resonated with a lot of what we were already feeling but kind of motivate us to finally do something like this. So I wanted to know directly from you, how do you feel so far about the working group and what do you hope to see the group accomplish?
Cassidy: Well, there's a fair lack of memes, so we need to improve that. I'm just kidding. It's been great so far. I was so happy to see what a good group of people it was. It was a really diverse group of people from a lot of different backgrounds. We even have some Vue developers in there and I think that is great. I've been really excited to see all of the discussions around it so far, and it feels like a very nice and open way of getting feedback from the community and a lot of the people in the group already, they talk with React developers a lot too. And so it's a great way of getting a lot of feedback without overwhelming y'all with all of the questions you might be getting in general.
Andrew: Yeah. Thanks so much. And again, thank you for, you know, largely inspiring this group. And we're really happy to have you be a part of it as well. So what we're going to do now that we've kind of done some introductions is we're going to move to question and answers. A reminder once again, for those just joining: please, if you have additional questions, you can send them to Ricky, you can DM him, or you can tweet at the reactjs account and we'll try our best to get to them. But we have some planned questions that we collected ahead of time. The first I'll read the question and then I have someone that that we asked to speak to it. Aakansha, I invited you to be a speaker. I don't know if you accepted it yet, but I'll ask the question and hopefully by the time we get to the end you'll figure out how to approve or accept that. But yeah, so this first question is: what is batching and why are people talking about this thing called automatic batching that appeared in some of the documentation that we published. Is that a new practice? And can you just explain what it is? Aakansha are you there?
Andrew: Let's see. I know she was there. If not, it's okay, we can have you maybe come on later. Maybe I'm just messing up the approval. Okay. There we go. I swear I'm doing this right. Just sometimes the UI doesn't respond to me. Aakansha I see you're you're on here now, do you mind answering this question about automatic matching?
Aakansha: So hey, I'm a Aakansha from the working group! So yeah, so the question was "what is batching and what is automatic batching in React 18?" Right. So batching is basically when React actually groups multiple states into a single render, so that you actually optimize the performance of the app. Until React 18, what would happen is if you set multiple state calls, if that even happens, React actually would batch those and made sure that there is only one render to optimize the performance. But let's say you have multiple setStates inside where a promise is resolved or inside a setTimeout anywhere outside the even handlers. Those are actually not taken care of by React. And that's where in React 18 we have this automatic batching. So irrespective of wherever you are actually setting the multiple states, it will actually batch them up and make sure that it results into one render. And thus boost the performance of the app.
Andrew: Yeah, that's a great explanation. Aakansha. Dan, I was going to ask you - you know, you wrote a really great document in the working group about automatic batching, which I thought did a pretty good job explaining it. You know, usually when we announce features, we try to announce them in terms of like, the user experience or like what it allows you to build, whereas automatic batching, you know, it's interesting, but it also sounds kind of like a low-level thing. So how have you been explaining it to folks?
Dan: Yeah, so I do have the main explanation, which is basically the same thing that Aakansha said that if you set multiple states we only want to render once. And so now we do that in more cases. But, I also wrote in this thread, I think it's called glossary (so if you searched for glossary in the discussions in the GitHub repo you will find it). People ask different questions, kind of "explain like I'm five" style. The explanation that I used is inspired by the explanation we'll be using in the new React docs that we're working on with Rachel Nabors. I think she's somewhere here.
Dan: So the the metaphor that I use is: imagine you're making breakfast (well, it depends on what you like to have for breakfast) but let's say you want to get some milk and get some cereal and so on. Imagine that you start making breakfast and you realize you have no milk. So you go to the shop and you get the milk and then you come back and you realize that you also have no cereal. So you go to the shop again and you get the cereal and then you realize that you have no, let's say sausage (I don't know if that goes well together), but again, you'd go to the shop and like, that's not a very efficient way to do it, right?
Dan: You probably want to first decide what you want to have for breakfast make a shopping list and then go to the shop and just get all of those three things at once. And so that's kind of like in the metaphor: going the shop represents rendering, and realizing that writing down one item is like setting state. So if you set state multiple times, we kind of want to keep track of that, but then do a single render instead of doing it many times.
Andrew: Yeah. I love that explanation. And it's very relatable because I've totally been that guy who goes to the store like five times in order to cook a single dinner. So yeah, really great explanation. So I think we have a good explanation of batching there, thanks Aakansha for raising that and for your great explanation.
Andrew: Rick I wanted to address the next question to you. Which by the way, a lot of these are composites from multiple people that we've heard from. So if I'm phrasing it in a way that is not exactly how you submitted it, then that might be why. But our next question is: "why would I need concurrent features in my app? And how would I use them?" And Rick also before answering, could you go ahead and explain again to folks: "What do we mean by concurrent features or concurrent rendering?"
Ricky: Yeah. So this is a great question. Thanks to whomever asked it. So what we mean by concurrent rendering is that there's a new algorithm in React that knows how to render components kind of in the background or differently than things that are like visible on the screen. And so if you've been following along in the experimental releases of React (no worries if you haven't) you may have heard of "concurrent mode" where the idea was that you would upgrade to a version of React and that version would turn on this new mode where everything was concurrent. And you may see different behaviors in your apps, just straight out of the box.
Ricky: What we did in React 18 is made everything work the way that it does today in your app by default. So if you're familiar with the synchronous lifecycle of React, or updates taking maybe a long time and happening all at once in a specific order, that's the same way that it will work when you upgrade to React 18. But once you switch to React 18 and switch over to our new createRoot API, you'll be able to start using these new features that will opt you in only in the the smaller parts of your app, where you use these features, to "concurrent rendering". And so what this means is that you'll be able to use features like a feature we call startTransition.
Ricky: To give you some background on startTransition, if you've ever you ever written a form input, where you type something in and then there's an update (if there's a controlled component). There's updates to the input field text, and then that text changing results in like some list of results rendering. If you tried to do both of those at the same time, then React treats both of those updates as urgent. But if you think about it, they're not both urgent. One is more urgent than the other; one is more important than the other. The update that's the most important is the update for typing. Because if you lag typing, it's going to feel really bad for the user, especially because browser built-in input field does not lag, ever. And so what we're giving you the ability to do in React 18, with concurrent features is tell React which updates are urgent (which ones the user needs feedback for immediately, which happens by default) and mark some updates as what we call transitions. Transitions are things that can happen -- maybe it's a very expensive render triggered by that update, or maybe it just conceptually a transition and should happen separately. And so you can have updates rendering kind of in the background, opposed to everything happening all at once. This will allow you to build better user experiences, because you'll be able to say things that are urgent and need the user needs to see immediately and things that are not as urgent. So it allows you to structure the work in your app better. Great question.
Andrew: Excellent. Yeah, and I think I'm really proud all you, Rick and everyone, who have done a really good job explaining concurrency, or at least like what we mean by concurrent rendering. Because it's something that we haven't always in the past did an amazing job explaining, and I think in our initial communications. At least we're trying really hard to make it not seem so intimidating and make it clear to folks that it's really an exciting thing. It shouldn't be a scary thing or a confusing thing. So great explanation, Rick.
Ricky: And one thing that I'll add: I think that what's great about this strategy is that if you don't see the value in these features, you try it out and you're like, "I don't understand like why I would want to do this". We're not making you do it. But we think that these features are really powerful. We think that like adding concurrency is something that can help you build better user experiences. And so we want to get it in people's hands and allow you just start trying it. And I think it's going to be really great.
Andrew: Yeah. Thanks again, Ricky. So I was going to invite Spike onto the stage real quick, but I don't know if he accepted, so I'll just ask this question for him because I thought it was funny. He said: "I always imagined it was pronounced re-ACT, not RE-act, but maybe I'm wrong. Curious if this is a universal pronunciation on the core team." And you know what it absolutely is not universal. I've stopped noticing when people pronounce it differently from me. So I'm glad you noticed that, but I don't think there is an official pronunciation. If we made one, it would probably make people mad by choosing the one that's different from what half the people say. It's like a gif/gif thing. But to be fair, I pronounce it the same way as you, so sorry if there's an inconsistency. We don't really impose that as part of our communications guidelines.
Andrew: So next I wanted to get to our special guest who I teased earlier. And as a lot of you already guessed, it is Tom Occhino or Tomo as we call him affectionately. Tom is -- how do I describe Tom. Tom has been on the React team from before it was even called "React". He's as OG as you can really get. And I just wanted to invite him on here to chat to him for just a little bit, because Tom made an announcement earlier this week that he is leaving Facebook and I guess leaving our team directly, I suppose, but not really. And so Tom, it's great to have you on here, I'm really glad you could make it. And yeah, so I'll just start with a question which is: You've been on the team for a long time. You've been our leader for a long time. So many of us associate React with you very closely. I assume you couldn't have imagined that React would get to the point it is now. I mean, maybe, you're an optimistic guy, but React is used by millions of developers today. What has surprised you most about the journey along the way?
Tom: Oh, that's a good question. And thank you for having me. But actually before I answer your question, it's pronounced re-ACT. I remember the day Jordan and I were discussing very early on what we should even call this thing. The original name for React was FBolt. There's some history there (I can tell the story another time). But yeah, re-ACT. To be honest, we never ever imagined that React would get as big as it's gotten. And I think, all we were trying to do (and perhaps unsuccessfully) with our initial messaging was share about the sort of problems we were facing as we scaled our engineering organization internally and the solution or, you know, sort of mitigation that we came up with. And so if you look at our initial sort of messaging--our initial video, when we gave this presentation at JSConf, basically all we said was like: "Hey, here's this thing, It's working pretty well for us. Give it a shot, you know, see if it'll, if it'll help you, if it doesn't no worries." And I think like, all we were looking for was just to see if the problems that we were facing were, you know, universal if other companies and other teams and individuals are facing them. And it turned out that over a long period of time, we learned that yeah, some of these problems were universal. I don't think we had any ambitions of getting massive adoption of React. You know, it certainly was not at an explicit goal in the beginning.
Andrew: Yeah, that's really cool. Let's see, you and Jordan, this conversation you were having that must've been 2013? 2012, maybe?
Tom: 2012. Yeah.
Andrew: That's like 9 years ago! Oh my goodness. Well, that's a long time, but then I was just thinking that React 18 - the germs of that are almost as long. Like even just the time that I've worked on, well it's called React 18 now, but we've called it Concurrent React, we've called it an Async React, we called it Fiber. Like that's, you know, five years old now, which is the majority of that span.
Andrew: So it is really just a total coincidence that you've announced you're kind of going on a well-deserved break this week, and we're also releasing a public alpha -- it's maybe a good coincidence, but what are your thoughts reaching this milestone specifically? Because you know, when I joined the team about five years ago, this was the first thing we tackled. I have a lot of really great memories about that fiber collaboration. I just tweeted out a link before the show to the website that you made called isfiberreadyyet.com. I have a lot of really amazing memories on this team, but that might be my fondest when we all got together in room and like tried to burn that chart down. So yeah, what do you think about this milestone?
Tom: I mean, this is huge, and I agree about that time. You know, somewhat deceptive of a management technique, I was like: "I feel like progress isn't happening fast enough. Let me make a website where there'll be able to track this over time." We had so much fun with that, but this milestone really is a long time in the making. And I think like our initial hypothesis for why we needed to move in the direction of concurrent rendering was really influenced by what we were seeing happening in native software. You have so much more flexibility to do off-thread work and to do scheduling and rescheduling of work. And I think we also had this hunch that like, you know, the industry and technology is moving in the direction, having more CPUs, but those CPUs themselves aren't necessarily getting faster and faster.
Tom: And so what's the right architecture here. And actually, I think we've finally, after a lot of research and a lot of iterations, especially on the new facebook.com, we've gotten to a place where actually it really is noticeable. It really does feel a lot better. And you can see that this is going to unlock the next 10 years of innovation in this space. And so this milestone is huge. I've been emotional about it as well as my extended time at Facebook. And I just feel this just sense of pride and joy and appreciation for this team and the journey that we've been on so far. And I'm just so excited about the Working Group and shifting the center of communication away from just being a hundred percent kind of internal on the team and really bringing the community in.
Tom: Last note on this: at the most recent React Conf, one of the things I said I really, really wanted us to do was start taking an active role in the community in both shaping it and bringing it in to be part of the conversation here. And this is just a really proud moment for me. So thank you so much to the team and also for having me on here, this is awesome.
Andrew: Yeah. Thanks so much, Tom. And as all of you can probably tell if you haven't met Tom before, all the good stuff that our team does, like the optimism that I hope we bring to everything, the enthusiasm, the ambition -- it all either directly or indirectly comes from Tom, which I think you could really see in the way that you can hear him talk about React and how much he loves the team and has loved working on this project.
Andrew: Also, I just mentioned isfiberreadyyet.com and Rick has reminded me that Sophie is on the chat. I don't know if Sophie wants to talk real quick, she doesn't have to, but she was an enormous part of that effort as well. So it's, good to see some long-time React alumni on on the call today. It looks like Sophie did want to say something real quick. So let me see add a speaker. Hey, Sophie, what's going on? She's connecting right now.
Sophie: Hi, I actually need to run right now. I have a meeting right now at 10:30, so I was just about to log off, but just wanted to wish you all some good vibes. I'm excited that what we had originally in the day, isfiberreadyyet.com has like made it all the way here. And soon it'll be in everyone's hands. It's been a long journey.
Andrew: Yeah. So exciting. For those of you who don't know, Sophie was one of -- I think the original open source contributor to React, right? And then she was on the team and she managed us for a little while, and she still is very much an advisor and a person that we look to, to help us when we get stuck with things. So really great to see, to speak to you, Sophie.
Andrew: All right, so let's dive into a few more questions. I see that we have some questions streaming in. Laurie suggested to me yesterday when I was asking her for advice that I should invite people onto the stage a little bit before they join. But I'm noticing that when I invite someone and they approve it, turns into a request and then I have to approve the request again.
Andrew: So anyway, if I say your name right here in the next few minutes, please send me a request, so I can just go ahead and approve you ahead of time. I think that would just make the the transitions between speakers go a lot more smoothly. So I think I'm going to ask a question from Oliver Lopez, (@oliverloops). I'm going to ask a question from Michael Chan and I think Mark Funk, I'll also also ask a question from him. So if y'all don't mind just sending me a request, then I can get to you when that happens. But before that, let me go to one of our planned questions so that you can give them a chance to send an invite or send a request.
Andrew: I'm going to direct my next question to Brian. So Brian, concurrent rendering is, you know as Rick gave an explanation earlier, it's a pretty cool feature of the new Reacts architecture that you can opt into. But it works a bit differently than what some developers are used to. It could take some adjusting before they develop a mental model perhaps, that's been our experience as we gave this to some folks during our testing. So how are we planning? How are you planning to help people understand what's going on when they see unexpected behavior? And the reason I'm directing this to Brian for folks that don't know is Brian is the kind of designer and developer largely single-handedly (not completely he has some help), but on our team he's the React DevTools owner. So Brian what are your thoughts there?
Brian: Hey so the short answer is that we're going to be adding new developer tooling for this over the coming months. We currently have an extension and also a standalone npm tool called React DevTools that lets you connect to React applications, whether they're in the browser or React Native and explore them.
Brian: And the tooling, the way it currently works, kind of gives you sort of two pieces. One's a tab that shows all of your components. And this thing is focused on what the current state of your application is (what the current props in state are). And then the other thing is called the profiler which historically has been focused on how fast your components are. And in old React terms, those, those two things made sense, but in the new concurrent APIs that we're looking at, there are other concepts that sort of fall between the cracks here, like I/O. So with suspense you could have a batch of work that takes longer than you expect, because one of the resources you're loading didn't get preloaded and your components were just waiting on data to come back.
Brian: Or some other things that we haven't talked about yet in terms of how the internals work there's some stuff that we'll talk about maybe in a little bit of with pre-loading and such, but we could also be working on some other things at different priorities at the same time. And the current profiling tools don't show you any insight about this. So if you see your UI looks slow and you look at the profiler and you see that the components rendered quickly, and you don't know why there's sort of a big missing gap here in terms of these two new areas. And so we're going to be adding some new tooling that gives you more insight into this, both which components took a long time suspending because of their I/O or maybe which render works were delayed because React was working on something else that was higher priority at the time.
Brian: And we have some pre-release versions of some of these tools already. I'm going to retweet a link to one, as soon as I finished talking here in a minute for anyone that missed it, for one of the new tools, but basically we're going to be adding more capabilities into the profiling section of React DevTools over the coming months. That sort of give you more insight here. And if you have questions about how this stuff works, or if you are digging into performance problems and you feel like there's something the tooling just isn't giving you, you can always reach out to either me directly or the team or GitHub and let us know. We get a lot of ideas for new features in the tooling from people like yourselves who are writing applications and have these questions. So please do share them with us.
Andrew: Thanks so much, Brian, and sorry, Dan, you want to go?
Dan: Can I add a small thing? So I wanted to clarify, Brian used the term "I/O" and I just wanted to clarify that refers to input/output, but that's just data fetching. That's what we mean by that. So essentially because we're bringing in a first-class integration of data fetching into React so it becomes something that React is aware of rather than something you just build outside of React, then that makes it possible to build tooling and visualizations that let you actually see which components were fetching data and for how long. And that's kind of why maybe like this screen is out of date and you can see oh, like this component was fetching data. So just wanted to clarify that.
Andrew: Yeah, that's a great clarification. And I would say Dan and Rachel especially try and keep us honest in terms of not using jargon when we communicate externally. So sometimes I forget and I slip up and use words like "I/O" or terms like "I/O" and yeah, thanks Dan for catching that. Cause React is useful for a lot of folks, not just software engineers, there's also designers, which I think that's a topic we might touch on a little bit later. So thanks Dan. I was going to say to Brian though, about the scheduler profiling thing that you're alluding to. As someone who has seen the existing version of that, I'm incredibly excited about that project. I think it's going to be super high impact. And once we get into everyone's hands, whatever confusion people might have about concurrent rendering, which hopefully not that much, I think that the DevTools profiler is going to be a really great asset for the community in clearing up those misconceptions, perhaps. And the level of polish that you see in the rest of the DevTools (largely because of Brian's efforts to make it that polished) I think you can expect the same thing from the upcoming features as well. So thank you so much.
Andrew: Okay, so let's get to another question. It looks like I successfully have invited Mark to ask his question. So Mark Funk, hi nice to see you again. Do you want to just go ahead and ask the question that you asked?
Mark: Sure. So I was looking through the docs for startTransition, and I noticed that there were two ways to call it: one off of what I think is ReactDOM with React.startTransition and another through the hook useTransition. And I noticed that you get a pending state with useTransition, but I wasn't sure why I would favor the hook over the global access or vice versa. And I'm curious to know if pending state is local to that one hook instance, meaning if I call startTransition from that singular hook is only the pending state set from that instance, or is it all hook usages or is it every startTransition call at the global level?
Andrew: Yeah, that's a great question. So I'll go ahead and enter this. The main difference between the hook API versus the one that you import from the React module is basically what you just said. One has an isPending that you can use. So isPending essentially, if you want to show a busy indicator. So if I'm navigating -- or if I'm refreshing the screen, let's say -- and when I hit the refresh button, there's already some content on the screen. It might be a little stale, but it's already there. So I like pulled to refresh on some like grid of items or something like that. Rather than hide all of the stale items, all of the existing ones, what you might do instead is show like a little spinner or like a shimmer effect to indicate that there's something going on in the background. And that's what isPending allows you to do.
Andrew: So that isPending flag is really the reason you would want to use the hook form. The one that you import from React (the one that is not a hook) has the exact same API just without the being able to use isPending. And it's useful for when you import and use startTransition from somewhere that's not directly in a component, like maybe a framework like a data framework might use this, or a router might use this internally. The idea is that you should be able to like use multiple startTransitions. Like if you have, let's say a framework or a library uses startTransition inside of its implementation, but then some user code inside an event handler, or like an onClick will wrap around that. You could have two startTransitions that wrap around an update. And that should work. You'll still get the isPending on the local hook form that you used. But it doesn't mean that it breaks the other usage of startTransition.
Andrew: And then in terms of like what is the isPending associated with? Yeah. It's associated with specifically the updates that you triggered with that hook's startTransition. It's a little hard to explain verbally, but I think once people use it it'll basically just work as they expect. We're actually still a little bit in the research area here. Like we might change the heuristics slightly. There's some research going into, like, if I have multiple transitions in a single queue, we should really only ever show the last one. So that's what we do. But maybe if you showed transitions across multiple queues, they should be allowed to finish independently. So we do have a little bit of work there, but the nice thing about the API is we will be able to tweak the heuristics a little bit later and it shouldn't affect how you use it. It'll just make for a nicer user experience. So I hope that answered your question. I think we might get into that a little bit later too, when we talk about Suspense. So I'm going to ask another question. Let me see if the people that I approved -- Oh, does someone want to speak?
Rachel: Hi, this is Rachel. I just wanted to clarify here. In the previous question, docs were mentioned, I wanted to clarify that those docs exist in the working group GitHub and can be read there. The live site docs are not the ones being referred to in that statement.
Andrew: Ah, yes. Very good clarification. Actually, this is a great segue, Rachel, cause I have a question I wanted to ask you, which is: earlier this week, you and Dan gave an update on GitHub about an exciting new project. Do you want to give folks the summary of that here?
Rachel: Well if you saw, last October we began an overhaul. Am I on? It says mic is on. Are we having connectivity issues?
Andrew: There's a little delay, but we can hear you now.
Rachel: And I turned it on and off again! Okay. So you might have heard last October Dan and I kicked off a project to overhaul React's documentation. As an example, the documentation is built into every release, but definitely could use a little bit more, well let's be honest, could use a lot of caretaking and tending. So we've been approaching with an all new user interface, all new curriculum. A lot of the content you may be familiar with from overreacted.io, Dan's awesome blog going into the specifics of how React works behind the scenes, all that is now going to be part of a fully extended set of guides and API references that should help you get good with React. Well, we will be launching a beta. Well, I don't want to give an exact date because then that would jinx it, but we are planning to share this content with the world by the end of the year. And we have out in the small group, sort of like the working group, but a little bit, a little bit closer to the chest while we were building out different pieces of the content. And it seems to be doing really well so far. So hopefully not too long now.
Andrew: Excellent. Thank you so much, Rachel. And as someone who's seen a sneak peek of the content that Rachel and Dan have been writing it's going to be real good. It's gonna be real good. I'm really excited about it. You know, it makes our current docs look embarrassing, that's how good they are. And I actually think our current docs are pretty good. But thanks so much, Rachel. I think everyone's really excited about that.
Andrew: So I'm going to read out a few more names like I did earlier. Whenever I say your name, it means I intend to ask you a question later, assuming I have time. So please just send me a request to speak that way I can approve you ahead of time and we can make the transition smooth. So Shruti Kapoor, Linton Ye (sorry if I mispronounced someone's name) and oliverloops, I don't think, I don't think I already approved you.
Andrew: So yeah, if you don't mind, send me an invite and that way I can approve you. But next let's go to Michael Chan, who has a question about research. Michael, do you want to share what you mean there?
Michael: Hey hey hey, what's up? I'm just so whelmed to be here and see all these faces and hear from everybody like Tomo. Yeah, y'all are awesome. And my big takeaway so far is that React is pronounced "FBolt". So that's a win I think for all of us. Yeah, so I do have a question about research and I think that there's kind of -- it can be a little bit opaque from the outside, like what discrete research phases there are. And I'd like to maybe get a little bit of clarity on that. Because obviously, you know, suspense has been in a research phase for like a really long time in terms of y'all working on it at Facebook getting the APIs, right. et cetera. But you also mentioned just recently that with the working group, some of the heuristics are still malleable and that's kind of, part of the work of the working group is to figure out the right heuristics, figure out some of the terminology that we should be using to refer to those things, whether they be like, kind of in that transitional time between seven and eight or kind of like eight on. And so I'm just kinda curious, like, do you have a way of thinking about that as we move forward? How ready are these things for the community to like pick up and kind of like, what does that community research phase look like for you all and what does success look like?
Andrew: Yeah, that's a great question. I think I'm going to direct this to Dan because Dan and I are now, it feels weird to say it, but Dan and I joined the team, like around the same time. Dan, a little bit before me. And so we've been here, along with Brian, I guess Brian joined around the same time too. We've been here since the beginning of the concurrent rendering -- well, not the beginning, there was actually research years before we joined the team, but at the beginning of the fiber project, I should say. So we have had a really close look at the whole life cycle of this really exciting, but longer than we expected (maybe naively) project. But Dan, do you want to go ahead and provide some insight on, like, what does it mean when we say research and how long does it take for these features to come to fruition?
Dan: Yeah, sure. I can give it a try. So it's actually pretty -- I think it's kinda tricky. So I think in general on this team we start with the theory and that's that's something that we have not communicated well. And maybe we should explain that better. But, the person that sets the technical direction for the team is Sebastian. He's been team lead for awhile. And he's the kind of person who really -- you know, when people come to him with problems, like "I want to do this thing in React" or like "I want to do that thing." He really goes back to first principles. Somehow he sees connections between things that seem unconnected to me as a kind of a product developer.
Dan: And he sees that, oh, actually there's some fundamental capability that if we added, then all of these things can be layered on top of that. And so a lot of the work that we've been doing over the past five years, they're driven by this kind of theoretical-first research Jordan did initially in 2014 when he tried it with React in a worker and that actually it did not work that well. And so that led to to like some rethinking and then Sebastian took over and he did his own prototypes. But it kind of starts with this theoretical research, and just the understanding that sometimes some approach is better than the other. Like in theory it makes sense that you don't want every state update to be a kind of a bottleneck. Like, even if you update a large part of the screen, it doesn't make sense to do it all at once. If from the user perspective you know, some things are more urgent than others.
Dan: And so it kind of starts with this theoretical understanding. But it's also deeply informed by kind of approaching it from the user perspective and design perspective. So it's kind of like this first stage is a blend of a kind of computer science approach, but also user perception. So, you know, like there's research on the user perception in that how fast people actually expect the interactions to happen and what is kind of the psychology and like, how do people perceive time and so on? And so we kind of start with that, and we make a prototype based on this. But then usually our first ideas are completely wrong or just like the way we implement them is wrong and the APIs are wrong. An API can look very elegant, but you can't really tell if it's going to work until they put it into production. And if you try to do it in a small app, it might seem like it works. If you like make a demo, it might seem like it works well. But then if you kind of just gave this API to developers and like have them use it for six months to build something complex and then come back, like, you'll discover a lot of interesting things.
Dan: And in many cases, we discovered it just doesn't work like this API doesn't compose very well. And what I mean by compose is, I mean that for every API we're building, that's like the core principle of React: things need to connect like Lego blocks. So it, it must be possible for different people working on different teams working on different components to just only know how their part works. And then the whole thing needs -- like when you put the parts together, they should still work. And that's the core principle of how we're approaching the API design.
Dan: And so eventually we find the right API, after the seeing how actually implement user interfaces, and seeing all the mistakes -- because we like Facebook we we do have a lot of control. So if we release an API in open source, in many ways, it's kind of game over. It's like, okay, if we want to change it that's like a two year release cycle to fix the mistakes, whereas internally we can just change it all at once. And sure, like maybe it will break something and maybe some people will be unhappy, but overall it allows us to iterate way faster and also see the results way faster.
Dan: And at some point we get to a place where the API kind of makes sense, and we see that people use it, and it composes well. We also learn about all the flaws and the implementation that we might want to fix and so on. And so that might take some time. And at some point it feels like, yeah, it's solid, it's ready for, for open source. And so this is usually when we put it in an alpha or like a beta, and we write an RFC that explains exactly how it works. And so on. And of course at that point, we take community feedback and sometimes at least the changes, like there's been a few changes like this, but in most cases, it is pretty solid by that point, because even though we only use it at Facebook, the patterns that people use UIs are not that different. It's like lists of things, it's like a thing that fetches some data, a thing that like animates from this thing to that, and like tabbed interfaces. Then of course, there are some cases that maybe are pretty different from what we're building, but overall both from open source the UIs that we see that React is used for, like in Twitter and Spotify and so on, we kind of get a sense that a lot of problems with similar.
Dan: And so in terms of the feature roll out at Facebook, the way we did is we usually start with one team. So when we have this draft of an API that kind of seems to work. We usually give it to one team, and then they give us feedback and we kind of like iterate on that until it works for that team's use cases. And then we try to expand. And so it's like a process, it's like working with clients: you start with one client, then you bring on another client and then at some point you covered most bases and then you can take on the whole community as a client as well. So I hope that that kind of explains that.
Andrew: Yeah, it was a great overview. I really liked the way you described it. So you talked about the first principles based model that we create, and then we try it out in the real world and then sometimes it doesn't work out. So then we have to go back and reincorporate our evidence and create like a refined model. Then we go back and we try it out again, it's like a cycle almost. And I wanted to give a specific shout out because Dan mentioned that we have people who test this out for us at Facebook. I want to give a specific shout out to what we call the React Data team at Facebook. And also the Web Core teams and Web Speed teams because they have been maybe our greatest asset all along as we take our wild ideas and try and put them into like a usable framework. So, in particular, the folks that maintain Relay: incredible help for us as we took these computer science concepts, as Dan said, and turn them into something that can be used by all React developers.
Andrew: Okay. So we're getting a little bit close to the end of the hour. We might go a little over, because we still have some more. I'm not gonna be able to get to everyone, unfortunately. But we still have some really great questions. If we don't get to everyone again, I am hoping that we're going to have more of these in the future. So this won't be your last chance and Rick's been doing a great job recording all of these. So we can probably just roll them over into the next Q&A that we do. But the next person that we wanted to talk to was Shruti and I think, yeah, she's here. So Shruti do want to ask your question? Are you there? I see you're a speaker, but I don't hear you.
Shruti: I'm here. Can you hear me okay? Okay, I have a question. My impression from the updates in React 18 is that the big theme is building performant UIs and removing the janky experience we have related to state transitions and batching state updates. Is that a correct assumption?
Andrew: So Rick, do you want to take this question? Ricky? Are you there? You don't have to, did I catch you off guard?
Ricky: Yeah, no, I was getting some of the questions queued up, but yeah, I can definitely take this. Yeah, I think that that's a good take removing janky experience between state transitions and batching state updates. That's a really big focus of this. It's also sets kind of the foundation for the long term vision of React. When we start thinking about suspense for data fetching and maybe some other new APIs that we'll be building off of the concurrent renderer, those would be the future. But what was really exciting about React 18 is how the out of the box features like automatic batching helped remove janky experiences or improve their performance of the box as well as like new concurrent features like startTransition will improve the state transitions. Yeah, I think that that's a great way to think about this release.
Andrew: Yeah. Thanks, Ricky. So we're reaching the end and there's just a lot of things that I was hoping to get to, but I guess that's a good problem that we had so much engagement. Maybe maybe this is yet another sign we need to do this more often. So there was a question from Linton Ye, I want to get him in real quick before we before we move on. So Linton, oh, I gotta approve you at a speaker. So yeah. Linton, do you want to ask your question? Just give him a moment.
Linton: Yeah. it's great to be here. So as far as I know that React 18 has put a lot of focus on UX. So making sure that it'll be easy to build performant UI and it'll be easy to precisely customize loading experience. So my question is about like you know, how does how do the designers at Facebook React to this change? Does it feel like it's mostly engineers work or does it feel like it's stuff that gives them some new superpowers so that they want to learn more about these this new changes and so that it'll improve their work?
Andrew: Yeah, that's a fantastic question. And I think it hits on this theme that I feel like we could have an entire talk just about this or entire chat just about this, but you know we talked a lot about how React JS is, at least our vision is, that it's not just for developers, right? It's not just people who go maybe like to a bootcamp or go to school like college or something for computer science. I guess the mission or the vision is that it should be for designers. It should be for anyone, even if they don't have a prior programming background. And the way that we do that is we route and we focus all of our APIs around user experience principles, not computer science or engineering principles. I mean, they're baked in there as we've alluded to, but you should be able to focus on the user experience and let React handle the complicated engineering.
Andrew: So we do have teams at Facebook of designers and they were actually very helpful when we were designing suspense. So we didn't really get to talk about suspense that much today, but you can go and watch some of the previous talks that we've given on suspense. I'll just give it like a very quick summary. I'm not gonna be able to give a great explanation, but like suspense, for those of you who don't know is three things: it's a low-level API that library can use to build like data frameworks or routers. It's also primarily for most people, it's a high level API for app developers to control the way that that views load onto the screen. And again, this this API is very centered around UX principles, not engineering jargon.
Andrew: And then it's also, In addition to the API itself, it's a suite of features and capabilities that build on top that should improve both the real and perceived performance of your app. So that lets you do things like throttle, the appearance of placeholder UIs to reduce flickers. You can load data in the background while you're showing the busy indicator as I described earlier. It's what powers our new streaming server render, which we'll probably get talked about in a, in a future Q&A, but you can also read about in our working group. Dan posted a really great architectural overview of how that works and why it's so exciting. Another promise of suspense is that it allows you to use this use the same high level API across all of the libraries that you use, whether it's a data router, images, whatever. It's integrated with the startTransition API that we mentioned earlier.
Andrew: And there's a lot of potential future features that we think will build on top of this exact same architecture. Brian and Luna have been working on this feature called offscreen (that's kind of the code name, it might be called something else in the future). So all of those things are very centered around UX principles both in terms of how we originally conceived them and in terms of the value proposition for folks and we worked very closely with our UX researchers at Facebook (in particular) to inform some of the design decisions. We have this idea that you if you're navigating to a new screen, you often have this effect where first you show a giant skeleton and then some data resolves. So you show like a smaller skeleton that as things start to narrow in and more of the screen fills in. We have this principle built in, as just an example, where as things are filling in from the outside in, we don't need to show a new nested spinner, like every frame, for instance. Like if data is loading really quickly, we can throttle the appearance of those, of those nested skeleton views, those nested placeholders. Because the user really doesn't need to see like five frames in a row of successive nested things appearing on screen. It's really bad for performance because you have to do all these read layouts, but it's also just bad for user experience because it makes the screen look all janky and flashy. So that's just one basic example. We could talk about that for a really long time, but I hope that kind of answers your question. So all right. We're at the end.
Dan: Can I add a really small thing? So I just wanted to clarify, because I think it kind of gets lost a lot. In retrospect, we kind of wish that maybe we should've called suspense something like Placeholder or Loader, because really it's a design concept, it's not a computer science concept. The idea is just that you already have somewhere in your code, in your components, you have those checks, like "if isLoaded return a spinner" or something. And really the main thing that Suspense does is instead of writing that, you put it into your tree. So you wrap a part of your tree with this Suspense component and you specify the spinner. And it might seem like a really small change.
Dan: But this way by putting something into the tree, we unlock all of these abilities because now React knows that it's not just some condition in your components and code, but it kind of moves it into the tree. And you can imagine for example, design tools, or no code tools like framer, or local tools like Webflow and so on integrating with that. And so you could imagine like building designs that are connected to data and just like visually connected: here's like a placeholder, here's like a data source. And then it would just work with any data source.
Dan: Or concretely to answer your question. How do designers use it? Yeah, we actually do have designers using this feature. And the way that works is for example, a designer can decide. Maybe we have like two granular load indicators and let's just show one. And so they can just delete the Suspense component from one place in the tree and add it to another place without touching any of the code basically.
Dan: And the other thing that designers can do is in React DevTools. There is a feature that lets you simulate what happens if any part of the tree suspense. So you can select the component, for example a post or a comment, and that feature already exists in the DevTools. You can press a button and it turns into a spinner. So you can see how exactly a UI looks if some part has not loaded. That's something you'd have to like mess with the code or know which part of the state in which components to change if you were doing it manually. But with Suspense, there is a single way to do it that can be integrated with the tooling, and that's that's kind of why we're excited about it, that designers can use it.
Andrew: Yeah. Thanks. It's funny because that was the original name of the Suspense component -- it was Placeholder. And in fact, the moment Dan started talking about it there was a flurry of activity in our team chat, people kind of going back and forth with "well, should we name it? Should we change the name? It's not too late." So maybe we will. Please, if you have feedback on that, just let us know. What do you think we should name it? What do you think we should name the suspense component? Should we, should we go back to Placeholder? I think Sebastian has suggested Skeleton at some point. I don't know. I feel like I change my mind every day there, 'cause Suspense is also a pretty good brand.
Andrew: Anyway, this has been a great conversation. Again I think we could have gone on all day here. But no worries because we're going to have another one of these at some point. Thank you so much to all the people who asked a question. If I didn't get to you today, I'm very sorry, we just had so much to get to. We'll try to get to your question next time. Ricky did an amazing job documenting all the questions that we got. So thank you so much to everyone. You can follow us on Twitter. You can follow our the React blog and you can go to the React 18 Working Group on GitHub, which is linked to from the blog post to follow along if you wish. And we'll have lots more to say about React 18 in the coming months including maybe as we get closer to a beta (as opposed to an alpha) we might have some nice some nice content for y'all explaining some of these additional concepts in detail and hopefully in a way that is understandable to everyone. So thanks again for joining. Thanks to my fellow React team members, thanks to the working group members who showed up and we'll see y'all next time.