Panel Discussion: The State of React

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

Naman created Stylex and has worked on React, including developing a React alternative for talks.

Jarrod works on Bun.

RSCs, or React Server Components, are a topic of discussion in the React community, focusing on server-side rendering and architecture.

The adoption of React Server Components has been slow due to challenges in understanding and implementing them, as well as limited integration with frameworks like Next.js.

Evan Bacon is the creator of Exporouter and works on Expo, React Native, mobile development, React Native Web, and bundling.

Sascha Grief runs developer surveys, including the State of React survey about the React community.

Improvements suggested include a public roadmap similar to TC39 stages, a permanent working group for community interaction, and better documentation for upcoming features.

Shruti Kapoor is a full-time content creator who focuses on React and AI.

Tanner Linsley is known for creating TanStack and giving talks related to React.

For native apps, React Server Components offer universal data fetching capabilities and allow for a more seamless integration between web and native platforms.

Tanner Linsley
Tanner Linsley
Naman Goel
Naman Goel
Evan Bacon
Evan Bacon
Shruti Kapoor
Shruti Kapoor
Mark Erikson
Mark Erikson
Jarred Sumner
Jarred Sumner
Sacha Greif
Sacha Greif
35 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Panelists introduced themselves and discussed React Server Components (RSCs), exploring usage in production and alternative frameworks. Challenges of adopting RSCs and benefits of universal data fetching were highlighted. The complexities of implementing RSCs were discussed, emphasizing the need for better integration. The potential of server components for composability and evolving architecture was explored. The React compiler's impact on performance optimization and component re-rendering was examined. Discussions included enhancing React with compiler features, evolving feature sets, and reimagining state management. Improvements in communication, community engagement, and dependency management within the React ecosystem were emphasized. Recommendations for managing dependencies, component performance, and audience appreciation were shared.

1. Panelists Introduce Themselves and Discuss RSCs

Short description:

Evan Bacon, Tanner Linsley, Sascha Grief, Shruti Kapoor, Naman, and Jarrod introduced themselves. The discussion shifted towards RSCs in React, with mentions from Mark and Tanner. The conversation delved into the usage of RSCs in production and explored alternative frameworks like Waku and Redwood.

Yeah, I'm Evan Bacon, I'm the creator of Exporouter, I work on Expo, React Native, mobile development, React Native Web, bundling. I'm Tanner Linsley, I spoke an hour ago. I made TanStack. I'm Sascha Grief, I run developer surveys, including the state of React about the React community. I'm Shruti Kapoor, I also gave a talk a few minutes ago. I'm a full-time content creator, I talk about React and AI. Hi, I'm Naman, I made Stylex, I did some work on React. I spoke, I made a React alternative for my talk. My name's Jarrod, I work on Bun.

Okay, great. So I think it's safe to say that one topic that's been recurring about React today, even yesterday in our discussions, is RSCs. And Mark, you've already talked about them a lot. Tanner, they were also part of your talk a little bit. And I'm wondering if there's other panelists who have things to add about RSCs.

One thing I've been curious about is, first of all, who has actually used them in production? By a show of hands. So does a personal website count? Production? I guess. Let's see, like for your actual day job for a company in production? No. Okay. Production. So that's already an interesting data point, I think. I like to run surveys, so that was a small survey. A good impromptu survey right there. But okay. So even if you haven't used them in production, does anybody have something they want to add on that topic? So I have like a couple of small thoughts. So one is, there's a few other frameworks that have RSCs implemented already and people don't seem to talk about them. The people who have used Waku say it's really nice and really fun and more loose, because Next.js is a more framework-y framework and has an architecture and Waku is like do whatever you want. And nobody talks about that one. There's Redwood, like rwsdk just shipped with it. Nobody's talking about that. And maybe we just need more people to try out those things to expand what people think of RSCs.

2. Challenges of Adopting React Server Components

Short description:

Discussion on the challenges of adopting React server components and the benefits of universal data fetching with RSCs. Integration issues in existing frameworks and the potential for future frameworks to incorporate RSCs from the outset.

More variety, would you say? More variety, yeah. So I think it was one of the questions we had before, but what's been preventing adoption of React components? Anybody want to take a shot? I'll start. So I actually led a panel at React. I'm going to blank out on the name. But in San Francisco, I led a panel there as well, and we talked about the same thing. What are RSCs and why adopt them? And I think since then, and up until now, I've seen the same common pattern, which is it is hard to first understand what RSCs are. But also once you understand them, to adopt them has been hard as well. And the sliver of slice where you can actually use RSCs and they have the right kind of advantage is small. So the adoption therefore has been very low. Like, for example, at Slack, we want to adopt RSCs. But we don't have Next.js. So how do we go down that route? I find it as one of the hardest things about adopting RSCs.

Yeah, well, we added server component support to Expo experimentally at the beginning of this year, and it's been pretty good so far. I mean, on native, there's, like, no data fetching. Like, there's so much variety for data fetching in the web, and we just have very little on native, so it's jarring to jump from nothing to this really comprehensive fine-grained granular system. And one of the benefits that we see from it is it's really, like, a universal primitive for SSR, SSG. Like, it's a system that you can apply to both native and web simultaneously. And when we look at, you know, people trying to code share, it's pretty straightforward to code share components, styles, maybe even interactions. But then, like, if you have to start forking at the router level or if you have to fork between platforms at the data fetching level, like, how authentication works, then it kind of all crumbles apart. It's just so foundational. And so with RSCs, we actually have an opportunity to build universal data fetching that works right at once and just runs pretty aggressively everywhere, which we find to be really nice on native. We can also do, like, little hacks where, you know, like, RSC payload, you need to stream that through, like, an HTML renderer on web. On native, you can just make the native runtime interpret RSC essentially as, like, native HTML. And so you get this more pure version of, like, sort of a React-first browser.

Do you think there's a cost in the fact that React wasn't born with RSCs and it's something that came in later compared to something like, I don't know, Astro has. It's not the same thing, but it was built from the start in that perspective of having the island architecture. Is there a future maybe some new framework that's going to integrate that concept right from the start? So, I mean, I think it's primarily an integration problem, which is, like, I saw very similar things even with Stylix where, like, once everything is set up, it's probably fun and nice to use, but setting it up is, like, such a hard thing that once you get stuck at the very, like, step one, you'll never use it. And I think just so far, like, Beats hasn't shipped integration and, like, Webpack was the only one, and even that integration wasn't, like, a super clean, easy, portable implementation. So I think it's just the tooling hasn't caught up yet. So in Bund, we actually this is not documented, and we haven't worked on it in, like, six months, but we actually have a React server components integration.

3. Complexities of Implementing Server Components

Short description:

Discussion on the challenges and complexities of implementing server components in React, including the need for better integration and clarification on the benefits of using RSCs.

It's basically in a very incomplete state. You can sort of use it if you're adventurous enough. If you pass dash dash app to Bund build, it has a file system router, you can do the back end, like, templating with JSX the way you would expect it to work. This is something that we eventually want to do a much better job of, but honestly, right now, we have we're, like, very focused on node compatibility, so we can't really spend time on it, but it's something that I think from a runtime perspective, like, the overlap of the Bundler with the runtime makes it so that we can probably have a pretty good experience here. Really focused on making it simpler to do the server side rendering parts in a way that actually makes sense without having to do the hydration step. We're still, like, not there yet.

Yeah, so that's interesting, and at least speaking personally, I think one of the benefits of server components, at least the way it was initially presented, was simplifying some of your code. You can maybe make a database query right from your component, but when I actually implemented RSCs, I ran into a lot of edge cases, as you might expect, which meant that my code didn't really get simpler. More like the opposite. So I wonder if maybe React components weren't, like, sold the right way, and I still struggle to articulate the reason why you should even care about them and use them. I'm curious if anybody can actually make that case, like, assuming we get over all the issues with should you use a framework or not, assuming somebody wants to get on board and is open to that, how do you sell the idea of RSCs?

It's kind of a cheap answer, but the short answer is go read Dan Abramov's blog, because he's already written a dozen posts about this topic in more detail than any of us could do. He's been approaching it from the perspective of if you know REST APIs, here's how server components is different and better than REST APIs. If you're coming from a GraphQL background, if you're coming from a different mindset, here's how server components come there. He's repeating the same thing in different ways, but he's both making the comparisons so that you have a familiar background to start from, as well as showing, but if you do a REST API, you keep having to add in all these extra fields that the UI needs for its requests, or you could just use a server component and format the data and send it down. I think genuinely the best answer here is read Dan's blog. He's done those explanations, and now we don't have to. So you're saying we should invite Dan next year? Also that.

4. Exploring the Composability of Server Components

Short description:

Discussion on the potential of server components for composability and the evolving nature of their architecture, along with a quick audience poll regarding familiarity and usage of server components in production.

Clap if you want Dan! Hopefully someone can show him the video. One thing that I really like about server components is, just like when I came over to React, it's just incredible. Now there's so many composable frameworks, but at the time it was like... The composability was really unmatched in React on the client side, so it's really exciting to think of a world where you could have that same level of composability for your server level, your backend for frontend, where someone could build a product and express it entirely as a React component. Almost like how WordPress plugins were for a while. You could just... I could see a YC startup, there probably are some already, that are like, here's how you use our product, like npm install this component, drop it in, and that's like the whole SaaS. You drop in your environment variables, you're good to go. So that level of composability is very exciting, and just the opportunity there for people to bootstrap a really complex idea with the simplicity that you get with React. We're not there yet, by the way, but you know, one of these days.

I don't know if anybody has more to add about server components. I mean, one of the things that is not brought up, like when server components, when I first saw the concept of server components, this was still at Meta, it was not announced outside, it was like very specifically made for newsfeed on Facebook, because there are, I don't know, 26, 38, I forgot the count, but a huge number of possible post types that a newsfeed can have, and almost all of them are fairly static, with a few interactive bits, and it was an optimization to not ship all these different components that you may or may not need, and if you could just run it on the server. And so that optimization was the original goal, but it has evolved into something else by the time it actually shipped, where it's more of an architecture, it's more of a data fetching thing, and I think because of all of the evolution and what it has become, like, there's no pinned down one part of what server components is, so when we have discussions about it, people are talking about different things.

To some people it's just a serialization format which can be used just to return data from a loader, and to other people it's this whole architecture where you have like mutations and things like that, and I don't think we can have a productive conversation until we settle that debate of what is server components, what is next JS's architecture, and where's the line. Yeah, that makes sense. Before we move on from this topic, I kind of want to take a quick audience poll, so raise your hand if you had heard about server components before today. Okay. That's been the framework. Almost everybody. This guy over here hasn't heard of server components before today. What about people who have used them or tried them out, let's say? Yeah, that's okay. 30%. 30% maybe? Yeah. So who used them in production on a real product? Like 15 people, 10 people, yeah? So okay, I think that's representative of the ecosystem as a whole. They have a big mind share, but practical usage is still a bit slow. Okay. Okay, so let's move on from this, and one question that people suggested was concerning which features of React are maybe underused, or you want to highlight something that people maybe already are using, but there's some hidden aspect where you can bring us little tips maybe? I'll go with one, which is I think the best addition to React in a long time is the use function. It's not a hook, so I don't know if it's named well, but it's very flexible, you can use it in different places. Right now it's only for promises and context, but what I'm most looking forward to is when it can be used for more kinds of data, which is something the React team has talked about. Yeah, sorry, go ahead.

5. Unveiling the Potential of the React Compiler

Short description:

Discussion on the potential and impact of the React compiler, highlighting its significance for performance optimization and the evolving understanding of component re-rendering based on compiler implementation.

I'm going to say the compiler. I think it's highly underrated, and even though we're having our own little growing pains with it, with TanSac libraries, it's pretty impressive what it can do. Especially just for user code, and I'm really curious to see where it's going to go. I don't know why, I just have this feeling that it's just the beginning of a big long journey into much better performance and maybe even flexibility of how we use React in the future. I think it's a really hot area where we can use it today. I think it's in release candidate, and it's pretty dang good, and yet they're also iterating quickly on it and learning a whole bunch of new cool things while they're building it. For me, I'm almost, and being very client-side oriented as well, it's directly applicable to the things that I build, and it's like I see the React team, I guess they see me when they're building the compiler, and I like to be seen. That's why I'm excited about it.

I'm actually curious, we do the same polls for the compiler. How many of you have heard of the compiler before today? Okay, pretty good number. How many of you have at least tried it out in a toy application? Relatively few. How many of you are running the compiler in production? Like, bye. Okay, got it. The point of the compiler is both that it's supposed to improve re-rendering performance, as well as, like, okay, so I thought, one of the things people have always misunderstood about React is the way the rendering model works, and that's why I wrote a 12,000-word blog post on the topic. Components do not re-render if the props change. Components re-render any time the parent did, which means if you set, say, here, it just automatically ripples through all the children.

The compiler does actually turn that on its head, and so if you've got the compiler active in a codebase, for the first time, it truly is your component only re-renders if the props data did actually change. This does start to lead to some questions. If we get to a world where we assume the compiler is on by default in most codebases, how do we actually teach things like the rendering process? Because there's the default behaviour, but then there's the way the compiler modifies that behaviour. Great question. We're probably going to need labours where it's strict, and if the compiler—right now, it fails gracefully, but probably it should assert that the language—because I feel this too, like sometimes instead of a use effect or something, I'll just have some top-level animation start, which is totally bad practice, but it works in the compiler, but then you might run some unrelated code in the compiler which then breaks optimisation, and then it changes the—it cascades and has all these side effects, so in cases like that, I would rather just enforce it's either on, or I get an error, but it's a migration strategy. I have a lot of faith that the React team would add more strict options.

6. Enhancing React with Compiler Features

Short description:

Discussion on the React compiler's importance and the transition towards strict mode by default. Emphasis on the accessibility and benefits of using the compiler, along with a wish list for integrated AI features in React.

Yeah. I think, yeah, right now we just roll it out very loose so that we can try to get more people to enable it, but at some point that will have to flip and it will have to be strict by default. Because the last strict mode was great. Yeah, yeah, every strict mode has always worked out. Perfectly. Yeah. I mean, the thing that a lot of people miss is compiler can already be either default on or default off, and you can turn it on or off for a component, for a hook, and so I actually don't think there's any reason for anyone to not start using it. I think 100% of developers should be using compiler today, and you can just not turn it on globally and just turn it on for a component, and if it doesn't break, just keep turning it on more components and you just get magically faster thing with no work.

Where could people go to learn more about how to do that? So the React compiler documentation doesn't mention the options, so you have to dig around to see how to turn it on on the npm package, but it's there. If you look for it, you'll find it. Sorry, I had to. So moving on from features that we wanted to highlight to now features that are missing from React, or maybe upcoming features that we might want to look for. New features coming to React? Either new features that are actually coming or wish list feature that you wish would come. Oh, wish list of features. Oh, man. Yeah, just integrated AI builder, like, by default. Like, you can add a token or something.

I don't know. One thing that I like about React is that over time, it used to be really heavy-handed, and there was, like, before JSX, it was like React.create, and then JSX came out very quickly, and then you had, like, React.create class, and then that kind of went away in terms of classes and functions, and it just kind of started to, like, disappear more and more, and then it feels more like React is like the language around the JavaScript. It feels more pure to the JavaScript in a way, even though it's kind of, and compiler does this, too. If you look at, like, where you still see React in a component, you've got, like, use memo, use callback, use effect, use state, and so, like, if you use server components, then you can get rid of a lot of use effect and use states.

7. Evolving React's Feature Set

Short description:

Discussion on the limitations of current React features and the desire for built-in error boundaries, improved state management, and data fetching capabilities within React.

If you use compiler, you can get rid of a lot of use memo and use callback to disappear. And so, like, when you were using server components and compiler and then you look at the results, like, where do you still see the React where you have to kind of step outside of the JavaScript and do something that feels less natural? Because like async in a way feels way more natural than use effect and use state. You know what I would like to see? Built-in error boundary. Please. It's about time. Then we can get rid of class components forever. Yeah. I mean, I'll just repeat the use function again. I'm, like, waiting for use function to support, like, signals and async iterables or, like, a fixed use sync external store. Like, I think that one hook being broken is probably the biggest flaw in React today because every ecosystem library for data uses it. And none of them are, like, safe for concurrent learning.

There's two things I want React to support. One is data fetching without an external library. I don't want to go to anybody else. I just want to fetch my data in React without anybody yelling at me that don't use use effect. And second, I want to manage my state in React without with something besides use state. Something that does not make me jump towards Redux or Zojtan. So I want React to be able to take care of data fetching and state management so I don't have to go for the libraries. I know you guys are gonna hate me because it's, like, your work. But I want React to be able to fully support itself until and unless there's a really good use case for it not to. I think that goes back to, you know, the framework versus library debate where should you have an all-in-one approach or stick to your lane and do something very targeted?

I know that the React team has said that they are at least exploring the idea of some kind of built-in store object that would not be tied to a specific component. I think that's still just, like, very early explorations. Something that's related but a little different that's maybe further along. So right now, external libraries like Redux, etc., rely on a hook called use-sync-external-store which subscribes something like the Redux store. And when the store is updated, it triggers a React rerender and that's the built-in, official-approved way for external libraries to connect to React. But it does have a limitation which is if you're doing concurrent rendering with either a use transition or suspense or something else, if there is a store update while React is sort of paused in the middle, then it actually kind of has to throw away the work in progress and start over and do an old-style start-to-finish render that might take up some time. So that's just an inherent limitation because the point of concurrent rendering is that React owns the state and it can say, start to apply this, whoops, no, set it aside, do something else, come back, reapply, finish. And if the state is external, React doesn't own it. It can't reorder things.

8. Reimagining React's State Management

Short description:

The React team is exploring a concurrent compatible store as a potential replacement for use sync external store, aiming for improved concurrency support. The desire for a first-party Zustand built inside React is highlighted as a potential solution for enhanced functionality. Implementing use external store could significantly impact decision-making regarding performance and concurrency support, offering a dual benefit for developers.

It can't reorder things. The React team did put up a PR recently for something that they're calling, like, a concurrent compatible store. All we have right now is, like, one paragraph in the most recent labs blog post and then a draft PR with the tests. So we don't even know what it looks like in practice yet. But if I'm reading this correctly, it sounds like it's supposed to be a replacement for use sync external store that would allow us to be concurrent compatible in some way. I hope. Maybe. Please. I would use that ASAP.

Yeah. So, yeah. I saw these PRs and I got, like, my impression was it was more like a first party Zustand and not a replacement for use sync external store yet. But I could be wrong. Who knows? We'll find out. I would be happy with first party Zustand built inside React. Yeah. So I think I ask Joe Savona for this once a month. I say, give me use external store, and he says, why? And I just kind of lower my head and walk away. But it really would be pretty amazing to get that hook or, you know, that utility out of React.

At least right now in a lot of the libraries that we have at Tanstack, we have to make decisions whether we want to either support very fine-grained re-rendering and selectors, which is usually where we default because we want the best performance that we can get. But we can't have full transition and concurrency support with that. So that is a fork in the road for us. And something like use external store, where we would be able to allow React to version our external state as it needs to, would fundamentally be able to let us have both of those. And that would be a big game-changer.

9. Improving Communication and Community Interaction

Short description:

The speaker discusses challenges in communicating new features and interacting with the community within React's ecosystem, proposing improvements like a constantly updated public roadmap and a structured approach similar to TC39 stages for JavaScript features. Highlighting the value of past interactions, the speaker advocates for a permanent working group and designated discussion forums for better communication and issue resolution within the React community.

So going back to your talk, one of the themes was this issue of how to communicate new features, how to interact with the community. And I think it's challenging for any project. Especially one of React's size and React's influence. So I'm wondering if you all have any ideas of how that could be improved? Is there anything the React team could do differently? Is there anything maybe the community should approach differently?

How many hours do we have? I have a laundry list of ideas but to keep a couple of them. One that I wish for that's probably not going to happen would be, like, a constantly updated public road map. Right now most of us just sort of have to either watch the React repository for an early PR, and then people get excited because this new feature is coming and then maybe it never shifts or it iterates through long. Ideally what I would like to see would be something kind of like the TC39 stages for JavaScript features, where they could say, this is stage one, we're not even committed to it, it's probably going to change, it's not final, but FYI, we're working on it. Just so we have some idea as a community where they think they're going.

In terms of communication, when React 18 came out, there was a public working group where they pulled in a lot of folks from the community. There was a public discussion forum where we could ask questions, we could forward questions that we saw externally, and then the React team would actually read those and answer them and there were some good explanations and discussions. I still think that was one of the best interactions that the React team has ever had with the community. I would love sort of like a permanent working group going forward, like when React App broke, after the release of React 19, I kind of whined about it a lot on Blue Sky because I didn't really have any other way to, I felt like I could communicate, and eventually that got fixed. But it would have been easier if there had been like a designated discussion forum where I could have said, hey, this is broken, FYI, and I would have known they were going to look at it and respond.

10. Community Engagement and Dependency Management

Short description:

The speaker highlights the value of a working group for community engagement before releases and proposes its continuity for upcoming releases. Emphasizing the importance of clear communication on feature development stages, the speaker advocates for a structured approach for community inquiries to core maintainers. Discussing common pitfalls, the speaker addresses the issue of managing dependencies correctly to avoid unnecessary re-renders.

Yeah, I plus one the working group. I think as an educator, it was such a great way to ask all the questions but also start building resources for the community before the release even came out. So there was a lot more to read and learn from outside of just what the React 18 docs said. One of the best threads that I still remember from them, from that GitHub discussion was explain like I'm five and they were like all of these bunch of different concepts. It's still live, still there. I think it was an amazing initiative to create a working group, and what I would love to see is for that working group to keep continuing for every oncoming release, but also to have a place where the community can go and ask questions from the core maintainers itself, especially for new upcoming releases like compiler. I have hundreds of questions. Where do I ask this?

Okay, yeah, I think that's a great idea, like a working group and also that stages system. It's definitely useful, you know, as someone who also keeps up with JavaScript and CSS and many other languages and technologies, knowing whether a feature is, like you said, an early idea that might go away or actually something that's going to ship to browsers imminently, that's super valuable, because otherwise it can be really hard to distinguish between those. So I think we still have a little bit of time left. Is there any other topic you guys want to bring up? Common pitfalls? Common pitfalls, yeah. Also we did discuss this previously. Are there common pitfalls in React, common mistakes that people make, maybe beginners, especially things that should be avoided? I think I'll start with one.

So having reviewed a lot of PRs at Slack and Paypal, a lot of the times we miss to manage our dependencies correctly, and that can lead to a lot of re-renders. So use memo, use callback, use effects, the three common hooks that accept dependencies that a lot of people use in code. There are linter tools that can actually highlight that you're missing a dependency. So number one step, install a linter tool that can help you highlight that. Number two, even though linter will highlight that the dependency is added, it's still your job to figure out that the dependency is granular itself, so you're not adding a huge object if you're not using the object. And the problem with that is whenever dependency changes, it will re-render and your component re-renders, there's performance implications.

11. Dependency Management and Component Performance

Short description:

The speaker emphasizes managing dependencies granularly and highlights the importance of using the compiler for setting dependencies correctly. Addressing common pitfalls, the speaker warns against large components for better performance and advocates for following React lint rules and enabling hooks. Exploring the benefits of the use API and React context, the speaker recommends avoiding large components for improved performance and functionality.

So the biggest pitfall that I would highlight is manage dependencies granularly. And just to clarify, you mean that dependency arrays for use effect and so on, not like the imports? Yes, yes, dependency array, thank you. On that I would actually say use the compiler, stop using use memo and use callback, and for use effect, don't try to write the dependencies yourself. Only make the yes lint rule write it. That's the only correct way. Every other way is wrong. The compiler will warn you also and will stop working if you don't write the exact dependencies that the yes lint rule writes. I think the only place where you have to make a decision is if you're reading a key off of an object, so like object.a, the yes lint rule might suggest object itself and you can put object.a, which is a little more granular, and that's usually better. That's it. Other than that, don't try to manage the dependencies yourself.

I agree that's the most common pitfall I see. Things break in very strange, subtle ways when the dependencies are off and there's no easy way to fix it because you start depending on that behavior over time and then you can never fix it. I mean, I saw earlier the stats about people, like there's some large percentage of people not using frameworks, so just make sure you're using the rules of React yes lint plugin and you've got the rules of hooks enabled, because that's basically the public interface for React to communicate with you, like the obvious issues in your project. And then don't, if you're on React 19, pull out all forward refs, it's therapeutic.

Another kind of subtle pitfall that I see is extra large components. It's fine to break up components. It's usually better for performance. Don't make mega components. With the new use API, I've been making my components extra large just so that I have places to use conditional calls. That's the thing, that's why I think it's a pitfall. It's very easy to make large components and then the larger they get, the worse the performance gets, and the more likely it is that you'll have some violation of the rules of React and the compiler will stop working. But if you have lots of small components, even if one or two don't work, if the rest of them are memorized, you get the performance benefits. It's great. Yeah. Yeah, people should definitely check out the use API and just all the new React context, because it does work, even though it just feels slightly different, the effects are profoundly different.

12. React State Management and Audience Appreciation

Short description:

The speaker discusses the simplicity of creating a context in React and the benefits of conditional calls and context selectors. Encouraging a blog post recap, recognizing the audience for their contributions to tool development, and mentioning the upcoming React survey in September.

I can only imagine someone learning about React from 19 on and maybe not reaching for a different state management library. Because oh yeah, just create a context, super simple. Even deleting the dot provider makes it just feel a little bit closer to a modern state management library, and then being able to call it conditionally, doing context selectors almost feels fantastic. So, whole new world, even with just slight API changes. Yeah.

Anything? Okay, well, you know, I think we covered a lot of ground already, so this might be a good place to stop. Someone should definitely write a blog post to recap everything we said. I'm looking in your direction. You can add it to the list, I know you've... You've been nominated. I don't have enough time to write all the stuff I want to write anyway.

And one thing we should remember is the people here not only are great panellists, but you guys actually make the tools that we all use. So I think you all deserve a big round of applause. And thank you for today, and also don't forget the state of react survey which will come out sometime in, like, probably September. So stay tuned for that. Thanks, everyone. Thanks, Satchel. Thanks, everybody.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.