You Can’t Use Hooks Conditionally… or Can You?

Spanish audio is available in the player settings
Rate this content
Bookmark

It’s the hooks rule number one: “Only call hooks at the top level”.


But what if I told you that this rule does not apply to every hook? One of them can actually safely be used conditionally. 


To understand how useContext is different from other hooks, and why it is exempted from this major rule, we need to know why this rule exists in the first place. We will build our own mental model of react’s rendering behavior, focused on how react keeps track of data at runtime: props, states, refs… and context values.

28 min
02 Jun, 2023

Video Summary and Transcription

The Talk discusses the use of the Use hook in React and its ability to be used conditionally. It explains the concept of the fiber tree and how hooks values are stored in memory. The Talk also delves into the conditional use of useContext and how it differs from useState. It explores the process of updating context values and optimizing context rendering. The role of the provider in managing context values and rendering is emphasized.

Available in Español

1. Introduction to the Use Hook

Short description:

A few months ago, the React Core team made a proposal to ask the community its opinion on the idea to add a new hook, the Use hook. Use would have a special ability. We would be able to use it conditionally. In the proposal, we then learned that use would not only be hindering promises, but other stuff too, like context values.

Hey everyone, I'm Charlotte, and today we are gonna defy the laws of hooks together. A few months ago, the React Core team made a proposal to ask the community its opinion on the idea to add a new hook, the Use hook. A React only version of Await that unwraps promises, allowing us to fetch a synchronous data and use it directly into our components. I'm not going to be dwelling on this hook today, but there is one thing about this hook that I'm interested in. Use would have a special ability. We would be able to use it conditionally. What? How is that possible? There are only two rules regarding hooks. Rule number one, only call hooks from React functions, so function components and other hooks, and rule number two, do not call hooks conditionally. Only two rules, and this hook would be exempted of like half of them? It gets worse. In the proposal, we then learned that use would not only be hindering promises, but other stuff too, like context values. We would be able to read context values with use, just like we do with use context.

2. Understanding the Use Context Conditionally

Short description:

To understand why use context can be used conditionally, we'll first need to understand why other hooks can't. When we build our app for the first time, React creates a fiber tree to keep track of our components. Each component is represented by a fiber object that holds information about the component. The fiber tree helps React determine which elements should be rendered and updated in the DOM. When we instantiate a React component, a new fiber is added to the tree. The fiber contains the component's type, props, and position in the tree.

So let me get this right. This means that we would be able to read context values conditionally, and actually, we've then learned in this tweet from Andrew Clarke that we already can. We already can call use context conditionally. But why? Why can use context be used conditionally, while other hooks can't? That's the question we're going to try to answer today.

To understand why use context can be used conditionally, we'll first need to understand why other hooks can't. And to understand this, we'll need to understand how hooks work. Where is a hook's data stored? How does React keep track of our data through time and render? To understand the difference of use context, we'll first need to understand React. So let's begin with this first question.

Where is our hook's data stored? Where is our component data stored? When we build our app for the first time, React is going to build this virtual tree made of our React components. This tree is called the fiber tree. The fiber tree keeps track of the React components that make up our app. And from this tree, React is going to inject our HTML elements into the DOM to display our application on the screen. The fiber tree keeps in memory through time and re-render information about our components, their data, their props, and their states. This way, when the re-render happens, React knows which elements should be—may have been changed, which ones should be rendered, and which information should be updated in the DOM.

So the first time we build our app, React creates this fiber tree. Every time we instantiate a React component, React adds a node into the tree. And such a node is called a fiber. Let's take a look at one of them. Let's take a look at one fiber at this greetings component. When we instantiate greetings, we're using this JSX syntax, and JSX is actually just syntactic sugar and is equivalent to the call of this JSX function, or create element up to React 17. And this JSX function, when it is executed, will create, we add, a new fiber into the tree. So when you instantiate a component with this JSX syntax, you actually add a node into the tree. You create a new fiber.

Now, what does a fiber actually look like? Well, a fiber is just an object that holds information about one component. So if we look at this greetings fiber, we have its type, we have its props, props data, I kept in memory inside every fiber, along with a bunch of other states and flags for React to keep track of, and finally, we have its position inside the fiber tree. Speaking of the fiber tree, let's see how it is built. Let's see what happens at first runner when our fiber tree is built. We are going to go through our code, and every time we instantiate a React component with this JSX syntax, React is going to add a fiber into the tree.

So first off, we have this app component that has the username in this state that it passes to this greetings component, which displays it into a paragraph, and finally, we have this button that we can click to change our username. And here we go.

3. Understanding Fiber Tree and Hooks

Short description:

We have built our fiber tree and injected our components into the DOM. Hooks values are stored in memory inside each individual fiber as a linked list. The function component does not retain data; the fiber does. When running the app, the values stored in the fiber are passed to the function.

We have built our fiber tree. Now what? This tree is still virtual. We haven't displayed anything on the DOM yet. So what React is going to do is it is going to inject our components into the DOM, but not all of them. Some of these components are pure React functions. This greetings component, for example, it's a pure React component. It does not exist in the DOM. It's not an HTML element. So what React is going to do is it is going to go through our fiber tree and every time it encounters an HTML element, it is going to inject it into the DOM. So our paragraph and our button. And now our application is live on the screen.

So our components data, our props, are kept in memory inside every fiber. Now, what about hooks? We are here to talk about hooks, right? So let's add a second state here. Where are those two values stored? Well, you guessed it. Hooks values are kept in memory inside each individual fiber as well, but not just in any way. Hooks values are stored inside a link list, where every value points towards the next one. These values are then read by the hooks in the order in which they're called. One thing you've got to understand here is that this function component, app, is just a function. It does not retain data. UseState does not retain data. The fiber does. When you run the app, you execute this function and you pass it the values that were stored in memory inside the fiber. So let's run the app for the first time. Let's build our fiber. We run the app. We are going to be writing this. This useState will be writing that default value in the fiber in the order in which they're called. So first off, we'll have name, which is going to be writing in the first element of the linked list as it's empty till now, Rachel. Then we have age, which is going to be writing into the current element of the linked list, .next. So the second one, 29.

4. Understanding Hooks and Conditional Use

Short description:

Now what happens after render? Can you see on this schema why you can't call Hooks conditionally? Let's try to call this name state conditionally based on this first Boolean value. We've got this error that you've probably already encountered in your lifetime as React developer. Hooks rely on the order in which they're called. They're all interdependent in their linked lists. This is why you can't use them conditionally.

Now what happens after render? What happens if we click this button right here and change our first state, our username? We are going to render. We are going to execute app and to pass it the values that were kept in memory inside the fiber. So first of name is going to be reading into the first element of the linked list and age into the second one. Can you see on this schema why you can't call Hooks conditionally? Hooks rely on the order in which they are called. So if at the next render you add or remove a hook, you change the order and the data you get isn't the good one.

Let's try to do it. Let's try to call this name state conditionally based on this first Boolean value which is originally equal to false. Let's render app for the first time. So first off we have shuname which is going to be writing false into the first element of the linked list. And we don't pass this condition, so we move on to age which is going to be writing 29. Now what happens if we click this button right here and change our first Boolean to true? We will render app and we pass it these two values. So first off shuname is going to be reading true into the first element of the linked list. Then this time we pass this condition, so we have name which is going to be reading 29. So yeah, name is going to be 29 and then we have age which can find its value anywhere and get us off. We've got this error that you've probably already encountered in your lifetime as React developer. Hooks rely on the order in which they're called. They're all interdependent in their linked lists. This is why you can't use them conditionally.

5. Understanding the Use of useContext

Short description:

Now what about useContext then? Why can useContext be used conditionally? Let's twist our example a bit and use provides our username into this context value. The answer lies into our fiber tree. So let's build it. First off we have this context objects, then we have app which still has the username in this state that it passes this time in props to this context provider. Below the provider we have greetings which is a context consumer now. It reads the context value from the username value from the context and it passes it to this paragraph. And finally, we finish up with this button that we can click to change our context value.

Now what about useContext then? Why can useContext be used conditionally? Let's twist our example a bit and use provides our username into this context value. The answer lies into our fiber tree. So let's build it. First off we have this context objects, then we have app which still has the username in this state that it passes this time in props to this context provider. Below the provider we have greetings which is a context consumer now. It reads the context value from the username value from the context and it passes it to this paragraph. And finally, we finish up with this button that we can click to change our context value.

6. Understanding Conditional Use of useContext

Short description:

Can you see on this schema why useContext can be used conditionally? useContext reads and stores its value inside a context object located outside of the tree, unrelated to other hooks. When calling useContext, the context object is passed as an argument, allowing direct access to the value. useState, on the other hand, relies on order to determine its value, as there are no identifiers to differentiate multiple instances. This distinction enables the conditional use of useContext.

Can you see on this schema why useContext can be used conditionally? Let's add a second state here. Hooks values like useState or useEffect read and store their value inside the linked list where hooks are all interdependent and where others matter. useContext on the other hand, reads and stores its value inside a context object that is located outside of the tree, outside of the linked list. useContext isn't related to other hooks the way useState is. So you can call it conditionally all you want. It just won't affect other hooks.

And that's actually something you can see in the code as well. Take a closer look at the code. See when you call useContext, you're passing it in arguments, the context object. You're telling it, go check out your value right here in this very object. It's hard-coded. useState on the other hand, does not receive any hard-coded key variable to find its value in. All it receives is the list of values of all of the hooks of the fiber. And this useState is just like this one. There is no identifier to differentiate them. So how does it know which one of these values belongs to it? It relies on order. That's the implementation that was decided. So this is why useContext can be used conditionally. This is why useContext is different.

7. Understanding the Update of Context Values

Short description:

To understand how a context value is updated, we need to understand how any regular value is updated. When we change the context value, React calculates a new version of the fiber tree that corresponds to the change. It compares this new tree to the previous one and applies the differences to the DOM. However, only the components that may have changed are rendered, not every single component. This calculation process involves duplicating the fiber tree, updating it to reflect the change, flagging the fiber holding the changed state, and traversing the tree to decide which components to render.

But something still seems to be missing. How does this work exactly, right? The context value is located inside this object. But if this object is located outside of the tree, how is it updated? And what actually is the role of this provider here? In order for our demonstration to be complete, I'd like to go a little bit deeper if you'd like, and to really understand how a context value is updated, how a context value works underneath.

Okay, guys, the next couple of minutes are going to be quite intense. To understand how a context value is updated, we'll first need to understand how any regular value is updated. So we'll get some theory here on React's rendering behavior. So bear with me. All right, how is a context value updated? Let's click our button right here and change our context value. Let's see what happens. We are going to rerender. We trigger a set state. What is going to happen is we're going to calculate a new version of our fiber tree that corresponds to the change that we've made to our new state, our new render. Once it's done, React is going to compare this new tree to the one of the previous order and apply the differences to the DOM. But when we calculate this new fiber tree, we don't actually render every single component of our app that could be inefficient, only the ones that may have changed. Let's see how this calculation process goes step by step.

So we click on this button right here to change our context value. We are going to change to trigger a set state. We are going to render. At this point, several things happen. First, as we said, we are going to duplicate our fiber tree. We are going to update this new fiber tree to correspond to the change that we've made. But until now, it's just the same. It's just a copy. Second thing, we are going to flag the fiber that holds the state that was just changed as needing to render. So to this app component, this app fiber, we are going to add this small render flag. And finally, we are going to traverse our tree. We are going to visit every fiber. And for each of them, we are going to wonder, should we render these components? If we do, we will render. Otherwise, we bail out. We wait, quit.

8. Rendering the App Component

Short description:

We begin at the top of our tree with the first fiber app. App is flagged for a re-render, so we re-render it.

We don't render. And we begin at the top of our tree with the first fiber app. So let's use this small work in progress flag just to keep in mind which fiber we are currently visiting. So app. Should we render app? There are two criteria for a component to be rendered. And if it matches either one of them, we do render this component. The first one being being flagged for a re-render. And app was flagged for a re-render. So fair enough. We re-render app. Let's add some color in this schema. Let's put in blue the fibers that were re-rendered just to keep it in mind. So we've re-rendered app.

9. Execution of Function Components

Short description:

Executing function components means executing app and passing the values stored in the fiber. When rendering app, new fibers are created for all components instantiated with JSX syntax.

What does this mean? It means executing its function components. So we execute app and we pass it the values that were kept in memory inside the fiber. So first off, we are going to read the latest username value that was just changed. And then we're going through all of these JSX. And here look. Look at this greetings component, we're using the JSX syntax here. And remember JSX is equivalent to the call of this JSX function which creates fibers. So what this means is in our new tree for this greetings components, we are going to completely discard the previous fiber and to add a whole new one. This is a new object. And something, yeah, let's put it in orange. New fibers are in orange just to keep it in mind. Something you've got to notice here and it will be useful later is that as we're creating a new fiber for greetings, we're creating a new props object as well. This is a whole new object. It will be useful later. So as we're rendering app, we are going to create new fibers for all of the components that it instantiates with this JSX syntax.

10. Rendering the Context Provider

Short description:

We render the provider, which is a context provider and updates the context object value based on its props.

So our provider as well to which we are passing the latest user name value in props and our and we are done with app. So we can move on to the next fiber, our context provider. Should we render the provider? Well, it was not flagged for render but there is a second criteria to be rendered and it is based on the props value. We are going to compare these props object, the props object of the fiber of the new tree to the one of the previous tree. We are going to compare these two objects through shallow equality and if they're equal, we don't render otherwise we do. And in our case, they're different. So we render the provider. So we execute this function component but that's not all. You see, this component is kind of special. It's not just a regular function component. It's a context provider. So, it does other stuff too, like updating the context object value, based on the value it got from its props. So the provider updates the context object value and we're done with the provider. So we can move on to the next fiber.

11. Rendering Components and the Fiber Tree

Short description:

When we create a new fiber for greetings, we create a new object for its props. Even though the objects may seem alike, they have different references. JavaScript's shallow equality considers empty objects as not equal. Therefore, we render greetings. We then execute the function components, read the latest username value from the context object, and create a new fiber for the paragraph. The paragraph and button are also rendered. React compares the new tree to the previous one and applies the differences to the DOM. It's important to note that there is actually only one tree in reality, but it's easier to think of it as two trees. The fiber tree, not the code, is the source of truth for knowing which components may have changed and should be rendered.

Greetings, should we render greetings? Well, it was not like for render but has its props changed? Well, actually yes, it has. I know, two empty objects, they seem very alike but this is a different object. So when we created a new fiber for greetings, we created a new object for these props as well. It holds the same, no, different reference, if you may. And in JavaScript, through shallow equality, remember that empty object equals empty object is false through shallow equality. So in our case, these two objects are different and we do render greetings.

So we execute this function components. We read the latest username value from the context object and we create a new fiber for the paragraph to which we pass the new username value. And we're done with greetings. So we move on to the paragraph, which is rendered, because its props have changed, just have four greetings. And we move on to the button, which is rendered as well. And we're done building our tree. Now, React is going to compare this new tree to the one of the previous order and apply the differences to the DOM. And now we're done. This was kind of mechanical. So let's take a step back from this. There's one thing or two that I'd like to discuss together. First about React and then we'll be talking about context.

About React, one small disclaimer. It isn't entirely true that we do have these two trees. In reality, there's only one. And every fiber holds on to its whole history of states. But I just find it easier to think of it as two trees. And I mean, it's my mental model. So if I want to have two trees, I'll have two trees. Second thing still about React. There's one misconception that I had about React that I wanted to share with you. I used to think that the source of truth, to know which components may have changed and which one should be rendered was the code. But it isn't. The fiber tree is.

12. Understanding Rendering and Context Usage

Short description:

When we render app, a new fiber is created for greetings, and the entire tree is traversed. React renders greetings when it detects that its props have changed. In real-life usage, the first components below the provider are rarely context consumers. Additional components can be added between the provider and the first context consumer. When the context value is changed, all components in the cascade are rendered.

I used to think that when we rendered app, the fact that we are calling this greetings component this way meant that we would be executing it right away. But that's not what's happening. What's happening is when we render app, when we execute this line, we create a new fiber for greetings. And then we're traversing the whole tree. And later on, when we're visiting greetings, React is saying, oh, its props have changed. We should render that. And only then do we execute these lines. The source of truth is the fiber tree.

Now in your daily life, I know you won't be drawing fiber trees. So what you can remember, what you can take away from this is when you're under—when the component is rendered, all of the components instantiates will get rendered as well. Now about contexts. This is actually how contexts work. We change the state value which regards set states. The provider is rendered. It updates the context value—sorry, animation problems. It updates the latest context—the context values—the context value from the context objects. And then all of these components are going to get rendered in Cascade and this gradient component is going to be reading the latest context value from the context objects. But actually we are not quite done yet. This does not actually represent a real-life usage of context. In real life, the first components located just below the provider hardly ever is a context consumer.

In real life, it looks more like this. We add up a few extra components between the provider and the first context consumer. Now in this case, if we take a look at these A and B components, do you think that they will get rendered as well if we change our context value if we click on this button? Well, actually yes. If we click this button right here, we are going to render app. So app, when it is executed, will create a new fiber for A. So A will get rendered. So it will create a new fiber for B. So B will get rendered and so on and so forth. All of these components are rendered in Cascade. But I mean that's too bad.

13. Optimizing Context Rendering

Short description:

We want to avoid rendering components that don't depend on the context when the context value changes. One way to achieve this is by memoizing the first component below the provider. Another way is to extract the provider into its own custom component and pass the rest of the tree as children prop. By doing this, when the context value changes and the provider is rendered, the components passed as children won't rerender. Let's demonstrate this by changing the context value and observing the rendering process. We duplicate the fiber tree, flag the component holding the state, and traverse the tree. We don't rerender app because its props haven't changed. This optimization allows us to avoid unnecessary renders and improve performance.

We have rendered because we changed the context value but A and B don't depend on the context. They haven't changed. We should not render them. That's too bad. And I mean when you call useContext, you're trying to call it as low as possible in your tree, as close as possible to where you actually need it. So if we can, it'd be kind of nice to avoid rendering all of the components located between the provider and the context consumer.

So how can we achieve this? How can we not rerender A and B if we change our context value? Well, one thing that I had already heard before is to memoize the first component located just below the provider. This way, we memoize this component. This way, we stop the propagation of render. This should work but actually, there is another way to achieve this, which is even closer to a real-life context usage. Can you guess what it is? It is to extract your provider into its own custom component and to pass the rest of the tree as children prop. This way, when we change our context value and auth provider is rendered, when auth provider is rendered, this A component that is passed as children prop won't and we will stop the propagation of render.

Let's make the demonstration real quick. Let's click on this button right here and change our context value. We duplicate our fiber tree, we are going to flag the component that holds the state as needing to render. So this time it's not app anymore, it's this auth provider custom components. So we flag auth provider and we begin traversing our tree. We begin with app, should we render app? Well, it was not flagged for render but has its props changed? Well, actually no. This time, this props object is the same as this one. When we duplicated our tree, this tree is the shallow copy of this one. It's a direct copy of this one, so this props object is a direct copy of this one. They hold the same reference if you may. In JavaScript, this time through shallow equality, these two objects are equal. So we don't rerender app. Did you notice? It's the first component for the last 10 minutes that we don't actually render. It feels great. All right. Let's move on to the provider. It is rendered as it was flagged, so we execute it. We get the latest username value and we create new fibers for the provider and the button.

14. Understanding the Role of the Provider

Short description:

But here, children is just a prop, it's just a variable. The provider is going to ensure that the context consumers are going to get rendered. AuthProvider, our context provider, is going to flag readings as needing to render. Extracting the provider into its own custom components not only leads to a better separation of responsibility, but also ensures that all of the components located between the provider and the first context consumer don't get rendered. The role of the provider is absolutely crucial. It is going to both update the context object's value inside the context objects and ensure the consumers will be rendered.

But what about this children prop? What about this A component that was passed as children prop? Should we create a new fiber for it? Well, actually, no. The reason why we're creating a new fiber for a button is because of this JSX syntax which is equivalent to the JSX function which creates fibers. But here, children is just a prop, it's just a variable. There's no JSX here, so no reason to create a new fiber for A. So no new fiber from A and we are done with the provider. We can move on to the actual context provider, which is rendered as its props have changed. It updates the context value and we move on to A, which is not re-rendered either. You see that just like for app, this props object is the same as this one, so we don't render A, nor do we B, nor do we greetings. But now we have a problem.

Greetings is a context consumer. We want it to get rendered to read the latest user name value, otherwise our app does not make sense. We want greetings to be rendered and actually it will. The provider is going to make sure of it. There's something I didn't tell you. Let's roll back to when we are visiting the provider. We said that when the provider was rendered, it would update the context object value, but that's not all it does. It is also going to ensure that the context consumers are going to get rendered. It is going to go through all of the fiber that are located below it and flag the context consumers as needing to render. It has this information inside the fibers because when a component is rendered, if it uses a context, use context is going to write this dependency towards the context inside the fiber. So AuthProvider, our context provider, is going to flag readings as needing to render. This way, even if a component is memorized in between and the propagation of render is stopped, it ensures that the consumers are rendered. And you can see that I didn't lie. This A component did not get rendered when AuthProvider was rendered because it was passed as this children prop. So actually, extracting the provider into its own custom components not only leads to a better separation of responsibility. It also ensures that all of the components located between the provider and the first context consumer don't get rendered.

And this is actually, oh yeah, sorry, one last thing. Once the first context consumer is rendered, of course, if you add up a few extra components below it, all of them are going to get rendered as well. And this is actually how context works. And you can see that the role of the provider is absolutely crucial. It is going to both update the context object's value inside the context objects and to ensure the consumers will be rendered so that they can read the latest context value from the context objects.

15. Conditional Use of useContext in Hooks

Short description:

With this full picture of how context works, we can confirm that use context can be used conditionally without interfering with other hooks. However, it is advised not to call use context conditionally to avoid confusion, especially for inexperienced developers. There may be other hooks besides use context, such as the use hook with Octobot, which can also be used conditionally. Thank you!

With this full picture of how context works, we can then confirm that indeed, use context can be used conditionally. It does not interfere with other hooks. So this is why use context can be used conditionally. And that's all I wanted to tell you about use context, this Curious Hooks.

Do I have one last minute to make a disclaimer? You have one last minute to make a quick disclaimer, go ahead. Thanks. Just wanted to say don't do it. Don't actually call use context conditionally. It's better for young girl developers to keep it the same way as others to make sure they are not lost.

And also, one quick question. Do you think that there may be other hooks? Is use context the only one? Remember, the use hook with Octobot? We said that we would be able to use it conditionally. Why is that? And yeah. Thank you so much. Here are some resources if you want to keep diving and keep building your own mental model of threat rendering behavior. That was awesome.

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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
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
Top Content
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 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
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.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
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.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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
Top Content
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
Top Content
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
Top Content
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
Top Content
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
Prerequisites- 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