Hydration, Islands, Streaming, Resumability… Oh My!

Rate this content

Our ecosystem can be overwhelming! First, we had the rise of SSR and SSG—and each had its own gigantic pile of frameworks and tools. Then partial hydration enabled us to hydrate only some of our components on the client, which we've seen in React Server Components. 

But what about islands? Do they relate at all to Streaming SSR? Moreover, what is resumability, and why do I keep hearing about it? […] Oh, did anyone say rendering on the Edge?

Well… There are many approaches out there, and all of them argue that their philosophy is best. In this session, we’ll go over these architecture/rendering patterns, to help shed some light on how some are implemented and the concepts behind them.

26 min
20 Oct, 2023


Sign in or register to post your comment.

AI Generated Video Summary

Today's Talk introduces the concepts of hydration and off islands, explores the benefits of islands for enhancing server-side rendered HTML with client-side JavaScript, discusses the lazy approach of re-zoomability and its advantages over traditional hydration, highlights the use of resumability and concurrent React for improved rendering performance, examines the features and concerns of React server components, touches on the co-location of client and server code, and explores future trends in rendering and navigation. The Talk also reflects on past ideas and emphasizes the importance of identifying core metrics for performance optimization.

1. Introduction to Hydration and Off Islands

Short description:

Today we'll discuss hydration, its challenges and issues, and the concept of off islands introduced by Jason Miller in 2020.

So, hello, London. It's just great to be here at this amazing conference again. And, yeah, I'm Mathias Apkarky, and today we're here to discuss about hydration, islands, streaming, resumability, and, wow, we should probably start, right?

So this is what we wanna cover today. We'll talk a little bit about the past and the future of things. And then we'll go to islands, resumability. We'll also talk about streaming SSR and how it combines with selective hydration. We should talk about React server components, right? And then we'll draft some closing thoughts on top of things.

And let's just start with hydration because, yeah, we wanna cover that. So if you're not familiar, I love this definition by Mishko, that hydration is the process of attaching behavior to declarative content to make it interactive. And hydration comes with a few challenges. So first, and obviously you have to associate the DOM elements with their corresponding event handlers. But also as a user, for example, triggers one of these handlers, you want to update the state of your app. And not only that, but once the state is updated, your framework needs to recreate the DOM hierarchy and everything. So hydration comes with challenges and hydration also comes with issues. And that's one of the most common ones. It's called the uncanny valley. And it happens exactly, so you got your initial request, you got your HTML and then you have your view painted, but then you have to wait for to arrive, to be executed, parsed, and everything. So the uncanny valley is this moment where everything is painted, but you don't have interaction, which is bad. And if we break down, it all starts, for example, when we get the HTML. And that's mostly fast, of course, but then you have to download JavaScript, and that can be slow depending on the network conditions of your users, as you probably know. Also, you have to parse and execute JavaScript. And that can be also slow depending on the capabilities of devices of your users. And also on the amount of JavaScript you're sending over the wire. And last but not least, your framework also has to recover, state, and bind all the listeners. And that can be slow depending on, for example, the amount of done nodes you need to go through. And also the amount of references that you need to rebind to those listeners. We could be here the whole day talking about the challenges and the issues with hydration, and you also have a lot of interesting posts out there. But the point is, throughout the years, people were trying to think of creative ways to fix or address, at least some part of this problems. And it was in 2020 that we started to listen a lot about the term off islands. And we got this name from this post by Jason Miller, the creator of React and also the creator of other amazing open source stuff.

2. Introduction to Islands and Their Benefits

Short description:

Islands are a way to selectively enhance server-side rendered HTML with client-side JavaScript, providing small focus chunks of interactivity. They allow for more specificity in enhancing the page and can be delivered and hydrated independently. There are various tools and frameworks available for building islands, such as Astro, Quake, Markle, Preact, Solid, and Svelte. Markle and Astro offer interesting combinations of features, including streaming, automatic partial hydration, and customizable loading strategies. Islands help reduce JavaScript code shipped to the client, resulting in faster page loads and improved metrics like TTI.

But if we dig a bit back in time, we find posts like this. So this is called Declarative JS Components with Vloader.js. And it was posted back in 2013, and it was about the idea of attaching JS behavior to chunks of HTML. So you can see that people were thinking about something like that.

And that's what islands are. You are selectively and progressively enhancing bits of server-side rendered HTML with some client-side JavaScript. And you have small focus chunks of interactivity within those SSR pages. And it's a bit of a mind shift, because you're going from this model where you have a single app in control of the full rendering of the page. To a place where you have actually multiple entry points. Also, usually with an island, this script for the islands can be delivered and hydrated independently. And it allows the rest of the page to be just a static HTML. But differently from other approaches to progressive hydration here, you have more specificity around how this enhancement occurs.

Another thing great about islands is that these days we have many ways to leverage them, so we have stand-alone implementations like Astro, Quake, Markle, and many others. And you can also use different tools to do islands with Preact, with Solid, with Svelte. And one interesting thing about islands is Markle. So Markle was there since 2014, it was open-sourced a few years later. But Markle shipped with this very interesting combo of streaming, with automatic partial hydration, and a clever compiler that would basically generate optimized code depending on where it was going to run on the client and on the server. Markle also had automatic partial hydration that basically allowed those interactive components to hydrate themselves. And the hydration code, of course, was only shipped for the components that needed interaction. Years later, we got Astro, and most of you heard about Astro, so in 2021. And Astro again had a very interesting combo. So by default, it was shipping 0 JavaScript, and every island could be loaded in parallel. Markle was also multi-framework, so you could build islands with React, Preact, Vector, and many others. And Astro allowed you to specify the loading strategy for each of your islands. So for example, if you're using a React JSX component with Astro and you're importing it, and etc., you can do things like this. So you can specify if that's going to be hydrated upon loading or when the browser's idle or only when your component gets visible. And you can do even more complex stuff.

That's what's great about islands in general. You're reducing the amount of JavaScript code that is shipped to the client also you can get faster page loads and better metrics related to that like TTI and others. And overall, you're making the key content of your site or your app available faster to the user.

3. Introduction to Re-zoomability and Lazy Approach

Short description:

Islands might not be a great fit if you end up with many islands and miss the point. Re-zoomability allows pausing execution on the server and resuming on the clients. OPA, Meteor, and Quik are examples of languages and frameworks that embrace resumability. Traditional hydration has an eager approach, while resumability takes a lazy approach. The client leverages deserialization to avoid redoing work.

Not to mention that you're getting the traditional benefits of SSR like improved SEO. Where I see that islands might not be a great fit is depending on the amount of interactivity you have, you might end up with dozens or hundreds of islands and then you might be missing the whole point.

Also in 2021, we got re-zoomability. And I think that a good way to think about the model of re-zoomability is if we picture that a lot of the things we have in the isomorphic landscape these days, they started on top of frameworks that were not initially fought for that. So for example, this is a post from 2013 where the Airbnb team was experimenting with server-side rendering backbone. And if we remember at the time, that's mostly what we had. People were experimenting with server-side rendering Angular or React or other frameworks. But what if we did the opposite? What if those frameworks, they started with server rendering in mind in the first place?

In 2011, we had this language, OPA. Has anyone ever heard of it? Okay, not us. One hand, wow. So OPA went way beyond just partial hydration. So you basically wrote programs and the compiler would slice client and server concerns for you. And that was amazing. Years later, we got Meteor, which had some of that in mind and also got some traction. And in 2021, we got Quik, which probably most of you heard about. So that's the idea of resumability. It's about pausing the execution in the server and resuming on the clients without having to replay and download all of the application logic. So pretty much it. Do some work, pause, resume where we left off. And you use what happened during the execution on the server to avoid extra work when the app boots in the browser. Also, it does that by attaching global event handlers at startup time, but only running then when it's necessary upon interaction. If you compare that with traditional hydration, I'm not talking about progressive or selective none of that, with traditional hydration, we have an eager approach where the event handler creation happens before those are called or triggered. Also, things are a bit more speculative. So all of them are created regardless whether they are used or not. And you also have the client redoing work and the framework has to download and execute the components to figure out their hierarchy. With resumability, you have the opposite. So you have a lazy approach where the event handler creation happens after the event is triggered. And also only the triggered events are the ones that are created and registered. So this happens as needed. Also, the client is not redoing work because it leverages a lot of deserialization.

4. Resumability and Concurrent React

Short description:

Resumability improves start-up and rendering performance by re-rendering only the change of components. Preloading critical page interactions and leveraging QUIC are recommended. Streaming-SSR, combined with Selective Hydration, allows faster interactivity and prioritizes hydration for user-interacted parts. This concurrent React approach eliminates waiting for slow components and improves overall page streaming.

So yeah, it requires a lot of important information to be included in the HML. If you're interested, there's this very great stream with Ryan from Solid and Mischka where they ideate the whole idea of resumability for a couple of hours. But that's what's pretty much great about resumability. It tends to improve your start-up performance and basically, also your rendering performance because it ships with other cool ideas like for example, only the change of components are re-rendered. Also, it brings fine-grained laced loading and progressive interactivity.

What concerns me about it though is that it's a best practice to preload your critical page interactions. So if you happen to have a lot of critical page interactions, you might have to preload a lot of stuff. Also, the only option we have these days to leverage Resumeability as it is defined is QUIC. So most of the discussions around it are in the QUIC community and builder.io itself, even though some people would argue that Marcoversion 6 brings something similar to Resumeability. But anyways, I have to say that I think that QUIC is a perfect example of outside-of-the-box thinking that sometimes is needed to fix issues in the web.

At the same time, it started in 2017, but it got more traction in 2022. We started talking about streaming things and then selective hydration. So Streaming-SSR was actually shipped with React 16 and only few of us were paying a lot of attention because we were discussing hooks, Suspense, the new Context API, and a lot of other cool stuff that also happened during React 16. Some people were leveraging Streaming-SSR at the time, but it got more traction after, mostly last year, after it was combined with Selective Hydration and other cool things from the concurrent React umbrella.

And it's good if we see how things happened before. So before React 18, hydration could only begin after the entire data was fetched and rendered for your page. So because of that, your users, they couldn't interact in the page until the hydration process was complete for all of that. And the bottom line here is that the parts of the app that were fast, they ended up having to wait for the slow ones. So it looks like this. All of these are sequential and blocking steps. So we fetch the data on the server, we render the HTML in the server, and then we get our first byte. And then we load it on the client, and we get our FCP. And only after hydrating, we get our first, our TTI. With StreamySSR and selective hydration, we can turn things into this. And now, React is going to prioritize hydrating the parts of the app that the user interacted with before the rest of the page. And because of that, components, they can become interactive faster by allowing the page to do other work, allowing the browser to do other work at the same time as hydration, because it's concurrent React. And of course, React no longer has to wait for components to load to continue streaming the HTML for the rest of the page. And when that specific part is available, it's going to be streamed and inserted in the right place by Script Tag. A lot of companies, by the way, they build interesting cases around this. Vercel has some numbers how they improve the Next.js website, some core web vitals in the Next.js websites by using that, including their INB.

5. Introduction to React Server Components

Short description:

React server components (RSC) were previously known as React Flight and were introduced in late 2020. RSC allows for ahead-of-time rendering during build time on a server and is integrated with data fetching and bundling. RSCs are similar to islands but do not have a clear boundary between server and client. The code for server components is not shipped to the client, providing better performance. RSCs also allow access to the backend from anywhere within the tree and can be refetched while maintaining client-side state. However, concerns remain about potential data over the wire and the orchestration of RSCs for framework and app builders.

So you might want to check it out. And then a year later, we also start to hear about React server components, which is funny, because if you've been watching discussions, it was there for a lot of time under the name of React Flight. So we just discussed the F things, like forget. So it was React Flight in 2018, 19. And then, in late 2020, we got this post introducing 0-bundle size React server components. And after that, it was a lot of the community, us, the team, like how did this piece together with suspense, transitions, and et cetera? So in my opinion, a good approach to get a grasp on server components is to think of them as if you could have ahead of the time rendering that can happen during build time on a server. But it's also a routing paradigm that is really integrated with data fetching and even with the whole way you bundle things. And as it might seem, it's not necessarily related to SSR or even hydration. Since we discussed islands, we can say that actually RSC is really identical to how islands work. But the thing is, when we were doing islands with Astro, for example, we had a clear boundary, what's Astro and what's React. With server components, we don't. That's why we have things like used client. Used client is marking a boundary between these two module graphs, the server and the client one. And of course, with RSC, each component can decide whether it's going to be a server component or a server plus client component. And I think that three things are amazing about RSCs. The first and, of course, probably what you hear mostly is the code for the server components is never shipped to the client, which is actually great because in a lot of SSR implementations we have these days, we end up having code bottle and sent over the wire. The second thing is, you get access to the back end from anywhere within the tree. And a lot of people see this as a bad thing, but actually, it's amazing. Imagine what you do with Next.js, for example, that at page level, you have things like get server side props, but now from anywhere within the tree. And the third thing is probably what I love the most is, those can be refetched while maintaining client side state inside of the tree. So think of an input components that you can refresh, re-render, but maintain, focus, hovering, that kind of stuff. So Ben prepared a really good example in this RC from scratch post. So this is an example of navigation without server components. And you can see that when you navigate, you lose the state. And here is the same thing, but with server components. And you can see that you navigate. And the state is not blown away. What concerns me about server component is that perhaps we might have situations where we get a lot of data sent over the wire on every re-render. Also, both from the perspective of framework builders, but also app builders, this orchestration of how this is going to work. And the final developer experience for me is still blurred.

6. Introduction to Server Components and Co-location

Short description:

RSCs bring an interesting discussion of co-locating client and server code. JacksR, a library from 2008, had similarities in coordinating client and server code. There's still much to learn about server components, with livestreams and side projects like Wacoo and TenStack Query. These projects explore colocation and extraction of client and server code.

But a lot of things about it are still experimental, in the end. And you have few options to leverage RSCs, mostly Next.js with the app router. But for me, RSCs bring a very, very interesting discussion that is this thing of co-locating client and server code, and how that's probably going to be the future. And it reminds me a lot about this thing called JacksR. Does anyone here know JacksR? Cool. No one. So JacksR was here back in 2008. And here's some of the official examples of using JacksR. But I want to highlight this script tag where you had this runAt attribute. And you could specify, for example, runAt server or runAt both. And if you put side by side the documentation from that library from 2008 and the state-of-the-art documentation, for example, with server components, you will see some similarities. Of course, they're not the same thing, but you can see that the idea of trying to coordinate the two was there. Anyways, I think that a lot of us, myself included, still need to learn a lot about server components. We had very interesting sessions. After me, Tejas is coming, and I'm pretty sure he's going to cover it really well too. There's a lot of livestreams on the topic you might want to watch, and also a lot of interesting side projects involving it. Wacoo, by Dai Shikado, is one of them. Where he's basically building his own implementation of RSCs. And you even have implementations in other ecosystems, like in Go, or even OCaml. And there is TenStack Query, TenStack Blink, sorry, by the same creators of TenStack Query and others, where you don't have RSCs per se, but it's a very interesting project to play with colocation and extraction of what's client, what's server code.

7. Future Trends and Holotypes in Rendering

Short description:

We'll be discussing routing, revisiting MPAs and SPAs, overcoming hydration challenges, achieving zero kilobytes JavaScript, and code extraction. The future may involve coordinating both client and server code, such as importing components with type clients. Solutions in rendering and navigation depend on the app's requirements. The Application Holotypes post explores different app types and their rendering and navigation approaches. The evolution of rendering HTML on the server has progressed from basic form submissions to pushing boundaries with initiatives like LiveWire, HotWire, and server components.

Wow. We covered really quickly a little bit of hydration, resumability, streaming islands, et cetera. And I feel like we could be here the whole day talking about a lot of other things when it comes to rendering patterns, but I wanna jump and talk a little bit about what I think is coming down the line.

So, yeah, I had to use a meme. But I think that we'll be discussing a lot routing and revisiting this whole thing of MPAs and SPAs, and where we wanna handle navigation, and revisiting this community decision of moving towards SPAs we had a decade ago. We'll also be discussing a lot about hydration and new and creative ways to overcome the challenges of hydration. We'll be discussing a lot whether we wanna have zero kilobytes JavaScript or not, and how to do so. And I think that we'll be discussing a lot code extraction. And as Dan pointed out a couple of years ago, I think that the next wave of technologies is gonna be about coordinating both clients and several code in a very, very fancy, in the best way possible. And have you seen, for example, this import attribute thing? It's an Akmah proposal. It just made it to TypeScript as a language. And with that you can do, for example, import JSON with type JSON. So I wonder if in the future, for example, we won't be able to do things like important components with type clients or both. I would love to see something like that. And more than ever, we'll be talking about why a given technology is the future.

So a few closing thoughts. As you probably notice, when you find a solution to your problem, you're probably just changing the problem that you have. And while a lot of these solutions, they seem competitive, I think that most of them are actually complementary. They don't solve the same issue all at the same time. Instead, they focus on different parts of the same problem. And that's why the same pattern can be good or bad, depending on which app, which part of your app, et cetera, which case you have. That's why I really like this thing. It's a post called Application Holotypes by Jason Miller, where he basically explored the different kinds of apps you can build, like a social network, an e-commerce, et cetera. And he proposes, OK, how do you want to build rendering for that? How do you want to build navigation? And Ryan Corneado even expands a bit more on that, talking about, for example, how do you want to do hydration? How do you want to do routing for each kind of these holotypes? So I really like it.

Another meme, and I think it's easy to think when we see all these examples with the app router, for example, and these new technologies, to think that we're just going back to rendering HTML on the server like we did back in the day. But the thing is, with PHP and Rails, the boundary, basically they were rendering that HTML and taking form submissions, and that was pretty much it. Years later, Marco tried to push the boundary further, but I guess most of us were busy building SBAs. And then, more recently, we had the PHP in the Ruby community and the Elixir community initiatives like LiveWire, HotWire, and et cetera, where they tried to push this boundary, but coming from a back end background. I think that quick and server components are an interesting attempt coming from a front end background to push this boundary while fully respecting what's client and what's server concerns. Also, as you probably noticed, software development is always going through cycles.

8. Reflection on Past Ideas and Future Considerations

Short description:

It's important to consider what's different now and what ideas from the past have become lost arts. React draws inspiration from techniques like double buffering in the game industry and previous experiments with Marcos. Addressing the complexity of network conditions and device capabilities is a challenge, similar to the unpredictable screen sizes faced in responsive design. Trusting future predictions and speculations can be misleading, as there is no silver bullet. Identifying core metrics, including business metrics, is crucial for performance optimization. I'm a front-end engineer at Medallia, a teacher at Tech Labs, and a Google expert in performance.

And it's important that we think that we're very likely not the first ones trying something. So it's important that we think, what's different now? And what was a great idea in the past and just turned into lost art? And I have two examples on that. The first one is this tweet by Andrew, also core committer of React, where he pointed that a lot of how React works with fibers and the whole tree comparison mechanism, et cetera, it brings inspiration from this double buffering technique that's been in the game industry for decades. And the second example is that when Dan posted that a lot of the cool things they were experimenting with React back in 2020 they were figuring out in Marcos back in 2014. And this post from Marco's team that he links links to another post that was posted back in 2005.

I agree it all sounds really complex, and I think it should, because we're trying to address a complex problem that is the variety of network conditions and device capabilities of our users. And if we think about back in the day of responsive design, we had a similar challenge. In 2010, we had to face an unpredictable amount of screen sizes, screen resolutions, and et cetera, so complex solutions for complex problems. That's the last one.

So you know what they say that a picture is worth 1,000 words. So this is me about a decade ago, and I was in this iOS meetup, and I was so hyped about Ionic back then. And I told them, you know what, stop building those native apps and just start using Ionic, because Angular's going to be the future. And here I am trying to talk about the future of React to you. So yeah, don't always trust those feature predictions and speculations and et cetera, because the cliche is true. There is no silver bullet. That's why it's important that you do identify your core metrics, and not only things like web vitals and et cetera, but actual business metrics, bounce rates, conversion rates, et cetera. Those performance metrics, they are important when they are matched with your actual business metrics. This is me. You can find me everywhere as wide accommodator. I'm a front-end engineer at Medallia. I teach front-end students at Tech Labs, and I'm a Google expert in performance. The links for this session and other sessions I have about internals of React, performance optimization, et cetera, you can find here. Thank you so much. I think we'll have like four minutes for questions, so thanks for having me. Thank you.

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

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
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.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
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.

React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn