State Management in React with Context and Hooks

Rate this content
Bookmark

A lot has changed in the world of state management in React the last few years. Where Redux used to be the main library for this, the introduction of the React Context and Hook APIs has shaken things up. No longer do you need external libraries to handle both component and global state in your applications. In this workshop you'll learn the different approaches to state management in the post-Redux era of React, all based on Hooks! And as a bonus, we'll explore two upcoming state management libraries in the React ecosystem.

71 min
10 Jun, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's workshop focuses on state management in React using the Context API and Hooks. The Context API is now a viable option for state management and provides additional features for effective state management. Custom hooks can be created to handle local state and access values from the context. Combining multiple contexts and using the useMemo hook can prevent unnecessary component rerenders. The useReducer hook allows for more complex state logic, similar to Redux. Debugging can be done by creating custom hooks and logging actions. Context can be used for global state management by separating providers into different components. The workshop includes exercises to practice using context and breakout rooms for discussion. The Q&A session covers fetching data and managing errors with context.

1. Introduction to State Management in React

Short description:

Today's workshop is about state management in React with Context and Hooks. I will show you some alternatives and how they compare to Redux. My name is Roy, you can find me on Twitter using the handle gethackteam. I'm managing engineering teams at Vandebron and working with the Sailor team. I've written books and given talks on React, React Native, and GraphQL. I recently created a book on creating full stack GraphQL applications.

Today's workshop is about state management in React with Context and Hooks. So I'm glad to see you all signed up and joined me for this workshop. So what is this about? I think if you're working with React you probably heard about state management from the beginning onwards and you probably have been confused and also reading out more about it every day because I think there are a lot of different topics in React state management.

When we started, or at least when I started working with React, I think everyone said Redux was the golden tool for state management, and often you would find at least if you were looking for a job like two or three years ago, you probably saw Redux as a desired skill for basically every company that worked at React. And also people are asking about React, so every time I did workshops people keep asking me questions about how to use Redux, how to implement it, why you should use it for state management or why not. And I think the discussion is still very relevant today. And even with new tools like the context API, it has become more and more relevant. Like, is Redux actually the best tool for your product? And should you be using it? So for today, I won't be telling you how to use Redux, but I will show you some alternatives and also how those alternatives compare to Redux.

A little bit about myself, so my name is Roy, you can find me on Twitter using the handle gethackteam, and currently I'm managing the engineering teams at Vandebron, which is a renewable energy company in the Netherlands. And I also work together with the Sailor team, and Sailor is an e-commerce API for actually more of an entire product, sort of comparable to what Strapi or GraphCMS is doing for CMSs, but then for e-commerce. It's also a really nice tool that is using a lot of React on the front end. And also you might already know me from some of the books I've written about React or React Native or talks I did about those topics, but also a lot about GraphQL, so if you're interested in that, please find me online. And also quite recently, I created this new book on creating full stack GraphQL applications, and it's both with GraphQL and TypeScript on the back end and also React and XGS on the front end, so if you're interested in those kind of things, yeah, you can find it here on this website.

2. Introduction to Context API and State Management

Short description:

Today's workshop is mostly about the context API and how you can use it to do state management effectively in any React application. The context API can be seen as sort of state or local state that wraps multiple components. You should be able to access this context value and also access functions to update the context value. Before a couple versions of React ago, it was advised not to use the context API for state management. However, a lot has changed, and now it is a viable option. The context API provides additional features that make state management more effective.

So for today, let's go back to state. And before we actually go into details, let's also look at what state actually is because state can be a lot of things, and state often can also be living just inside a menu. So I think two years ago, I was creating a nice open source library for the city of Amsterdam, so also the city where I'm living in, and over there, we were working with state, of course.

We also created a component library so in that we also worked with menus and menu items inside such a menu. And the menu looks something like this. So you would have a simple menu that could be open or it could be closed, and whether it was open, the state went through, and we decided to display a submenu. And in this solution, we almost always pass state down. So you can just create a menu, and you pass state down, whether or not the menu's open, and then based on that, you will do something inside maybe a child component, you maybe render a child component.

And in this solution, you almost always use local state, so either a state in a class-based React component, or maybe if you're using function components, then you would use the useState hook. And I think for simple things like this, like having a menu, having a submenu, or maybe just a menu item, you always choose to use local state because it doesn't really make sense to implement something bigger, like Redux or the Context API or maybe one of those other tools that are around. But if you have a more complex menu, you already need to consider if you still want to be using simple local state in React. Because maybe you have a menu, you'd have a submenu, there's a menu item, or maybe the menu item inside the submenu is another submenu, so in theory, we could go indefinitely far.

And in this solution, it's already good to start thinking about state like how complex should my state be? Or how simple should it be? Because this could be an example of your menu. So maybe you have a hamburger menu for mobile devices. It could be open or it could be closed. So you still have simple state like open is true or false. But maybe you also have a child inside that could be open or closed, so maybe you also have state for the opened or closed child in there. So this is already starting to look a bit more complex, and especially if you want people to stay in the same state whenever they refresh the page. I think it's getting more and more complex, and those are things you should think about.

And also you might be using, if you worked in a component library before, you probably have been wondering about accessible components. So if you want your component to be accessible, you want certain parts to be highlighted whenever someone uses the keyboard to navigate instead of their mouse. If you would be in such a situation that maybe you also want to know which child is selected, so you don't only want to know if the menu is opened, if a submenu is opened, or actually which submenu is opened, but you also want to know which child is selected. And it goes pretty far, and it also depends on how far you want to go, because I don't think you need to define IDs in state to determine which submenu is opened, but maybe if you do want to do this, it already gets more complex.

And this is still something you can quite easily use local state for. But there's already something you need to think about if you would still pass the prop zone. And I think for these scenarios where you would have a menu with a menu item, or maybe a menu with a submenu, or multiple submenus and menu items inside there, I think it's probably straightforward to say you could just pass state down, you create local state in the parent components, and in there you pass it down as props. And in the parent component, you will manage the local state, you will make sure that the menu items are opened or closed whether or not the actions someone is taking in your application. But what if these components aren't menus or submenus or menu items? So what if these components are your entire application or maybe even routes inside your application or components inside routes inside your entire application? If you would be in such a situation, then probably you won't be using local state anymore because you want your state to be more diverse.

And when we talk about more diverse, I always think about the chessboard. So chess has been becoming more and more popular, I think, especially with all the Netflix shows and all the cool documentaries about it. So when you think about state, you can also think about a chessboard. So do you want your state to be simple? Do you want your state to be able to pass one field by one field or one component by one component? It's actually the most basic piece in chess is, or do you want your state to be more complex? Do you want it to be able to maybe skip components or skip fields to be able to go back and forth? Is that something you want your state to do? And if that's a scenario, then you won't be helped enough by using just local state with maybe you state hook or maybe even you seducer hook. That's a scenario you probably want to do more and you actually need more.

And with that scenario, maybe you could have ended up using context API or using use reducer, but before those functions were available, you probably ended up with using something like Redux or MobX, or if you're using GraphQL, something like Apollo. And all these libraries were created because React lacked certain futures and able to do state management. Especially in able to do state management effectively. So I think the context API helped us a lot by adding these additional features and I will show you how you can use it.

So the agenda for today, we will be mostly giving you a more introduction for about 30 or 40 minutes, and afterwards, I'll be working on exercises in breakout rooms. And then during in between, we can sync to look at the exercises. So depending on how fast everyone will go today, maybe we won't be able to do all the exercises at once. Luckily, we have the Discord channel, and I think I shared it in the chat already, and Lira was also there. So if you're not in the Discord channel, then please let her know through Discord, and then she can add you to the channel, and we can discuss the exercises even after today's workshop. So today's workshop will be mostly about the context API and how you can use it to do state management effectively in any React application. And actually, before a couple versions of React ago, it was advised not to use context because if you want the application to be stable, don't use context, it's experimental.

And I think it was a really good message because a lot has been changed to the context API. And some people even still say you shouldn't use it for state management, but I think it's also a bit of a more opinionated question to ask to a lot of people. But before this React version, it was actually advised not to use React, a context API for state management. And actually React was also telling you, or at least the React documentation was telling you, if you aren't familiar with state management libraries like Redux or Mopix, don't use context and just use these libraries because they are better tested, they're built by the community and they might have a lot of features that you otherwise wouldn't have. So how does the context API work? So the context API can be seen as sort of state or local state, or doesn't necessarily have to be local state, but could be local state, that wraps multiple components. So from multiple components, you should be able to access this context value and also to access functions to update the context value.

3. Implementing Context API and Using Hooks

Short description:

To set up the Context API, you need to create a context object using the createContext method from React. This object holds multiple components, such as the context provider and consumer. You feed a dynamic value to the provider, and then you can consume it using the consumer component. The setup is similar to Redux and other providers like Apollo for GraphQL. You create a provider that wraps your application, and from anywhere inside the application, you can access the values using a consumer. You can also use hooks, such as useContext, to consume the context value without needing to use it within a render. This provides a more declarative and convenient way to use the context value.

And creating a context can be done by the method createContext from React. And this method will help you create a context object. And a context object will hold multiple components, an example, like the context provider. So you always start with creating the context, after which you can create the context provider. So my context in this scenario consists of two things, so context.provider, and also context.consumer. And you actually need both in order to set up Context API.

So at first, you always need to create a context provider at which you'll feed a dynamic value. So this is setting the context value, after which you're able to consume it using the consumer component. And the consumer component makes the context value accessible, just as you see it here. So the value it puts in the context provider is the same value as you would read from the consumer. And this is all being done by using React Components, and there are other ways to also read the context value, but that's what I show you later.

But you might already think this looks familiar, right? Because if you have been using Redux before, you probably see that with React Redux, you have the same setup. So you create a provider, you add a store to it, and the store is actually your context value. If you look at the context API, and you have to provide a wrap your entire application. So from everywhere in your application, you're actually able to read the store value from a consumer. So the setup is sort of the same and the approach is also the same. So if you come from Redux, there isn't that much that is different in terms of setting it up. And also if you've been using React with Apollo or maybe some different provider for GraphQL, then you probably see that with Apollo provider, you do sort of the same thing. So you create a provider, you don't pass actually a value to it, but you pass a client to it. And with this client, you can connect with the GraphQL API. And also this provider wraps the entire application and from anywhere inside your application, you're able to access the clients. You're able to make calls to the GraphQL API in order to get certain data. So the setup is still the same. You create a provider. It wraps parts of your application or maybe your entire application. And then you're able to access these values from anywhere inside the component tree that you wrapped with it using a consumer. So hopefully this looks cool and also a bit familiar if you worked with React for a longer time.

So how can we implement this? So there are actually multiple ways to implement it, but this is like a very basic way to do it. So we already started. You first create a context and using this context object, you will get a provider from it, which you will feed a dynamic value. And inside the provider, you will put a component as a child to this React component. So the component that we'll see here is actually a child component, and the child component is able to consume our React context. So this is still very similar to how we do it with Redux and React, but also with other things like Apollo. We have a provider, provider has a value, and that value you can consume it from any component inside the provider. And you can also do this with hooks, because hopefully you've all been checking out function components, and probably for a lot of you, function components are your main way to create React components. So of course, with the context API, we can also use hooks. And it looks pretty much the same, so you would still have to create a context, and then using that context, you can call the useContextHook from React. So just as useState or useReducer, this is a built-in hook. So this built-in hook, you can pass it your context object, and then you can get the context value already using this hook. So you still have a context object, and you still have a provider to pass the value to, but instead of having a consumer component, you're actually been passing your context object to the hook, and then you're able to read it and use it inside your application. So I think this is a way, a way nicer way. It's maybe a bit less declarative, but still it gives you a proper grounds to actually use the context value. And also what I really like, you don't have to use it within a render anymore. So when having the consumer, you also need to access the value from within a render. And by using hooks, you no longer have to do this. So this is something I like from hooks in general and function components, but it's also a nice addition to using the context API, not having to get context provider value from inside a render, but just using a hook. So let's compare the two approaches. So the top one is where you have to consume from inside a render using the consumer component. Or the other approach is where we have to use context hook in which you'll consume the context objects. So in both scenarios, you still need to import the context object.

4. Updating Context and Separating Concerns

Short description:

You can update the context by providing an update function. Use the useState hook to create a state value and pass it to the provider. By separating providers from consumers, you can prevent performance issues and make React more performant. The DevTools profiler can help you see what's going on when you separate concerns. Export your context object to access values from the context and update them from any component inside the component tree.

You still have my context consumer that you need to import from my context. And the other approach, you still have to import contexts object and use the hook to read it. So updating the context, we already saw that the context value is a dynamic value and it's something you can pass through it yourself. So updating the context can also be done by providing an update function to the context. So how did this work? So this is the thing we saw before. So you can create a context and then you will get a context provider that you need to set up and you can pass it any dynamic value. So what is this value? This value can be anything. And preferably it will be something that has to do with state because if we're using state of React, we already have update functions, we already have function that are dynamic and we're already triggering React to updates whenever we change something. So updating the context can be done quite easily if you look at how you use a useState hook.

So you would still have to create the context value, you have to create a local state value. So we will be using the React useState hook in order to create a state value. And the setup here is quite arbitrary. If you use a prediction, it looks a bit different because you almost never create a state object using useState for that you use reducer hook but more on that later. But it does show how you should approach this. So you would use the useState hook to create a state value. And a state value is something you pass to your provider. And also to your provider you would pass the update function for your local state. So your provider would exist of the state variables, but also for the update functions for your state variables. And by passing these to the provider, you're able to consume it inside your application. So if we're right here, you can see we have a context consumer. We're consuming the context value, and we actually be using the update function from inside our context to update the state value, which will then update our context value again. So by doing so, we actually make use of React's internal state management for local state. And we actually have been passing this into our context and able to use both of them. And by this, we get lots of approach advantages because we're already using internal systems of React. We don't need to create something. We don't need to use something from an external library. And this is all just React, which is also something I like. And while doing so, it's I think that we've reached the important part of, whenever you're doing this with React, you need to make sure that you separate concerns from each other, because if you approach state management like this, very easily we get to situations where you would have performance issues. And performance issues are probably, well, not that big of a issues because React itself is still performant and probably you will get very small lags, maybe even of milliseconds. So it isn't something really to worry about, but it's something you can prevent from happening by really separating providers from consumers.

So what do I mean with this? So with separating providers from consumers, you can have a look at this approach, you can actually create components that have just a context provider and that rep all the components. So your context provider can be a component that has the provider from your context object, but also has all the local state variables. And by separating providers from your consumers, you'll be able to really make sure that no unneeded updates are being done, because you already know probably, if you put a lot of different state variables in one React components, and then everything will update whenever something updates. That's something you want to prevent. So by separating concerns, you can make React more performant, you can also make it easier for React or maybe even Next.js if that's something you're using to know how components are aligned, how they work together. And it's also something that's quite interesting to see. And if we look at the DevTools for React, you have the profiler there, and in this you can actually see what's going on if you start separating these concerns. So whenever using the context API for something a bit more complex than maybe just having dark mode on or off in your application, make sure to separate those providers. And you can easily do this by just creating a new provider component, which is just a React component that has the provider from your context object. And in here you can see whenever you're doing so, you're just passing everything you put inside there as children. So the entire component tree that is not just one component, you just pass it in there and you have the children prop in React, which you can just use inside your provider and then return all those children. So this is also something it's not rocket science, it's something you, yeah, something you know if you're using React, the children component, something you just pass to it. And then you can easily pass the entire component tree. And also if we're updating context and we have separated those concerns, you also need to export your context object because your context object would live in your provider component. And then of course you need to export it. I usually use context to, we can use this context object to get all the values from our context, which is now just count and update context. And in this, you can just update it from any component inside the component tree. So we can see component here is now just one component with some HTML elements, but it could be an entire component tree. So from everywhere inside this component tree, we'd be able to use this use of context hook in order to get values from your context. And then you could just update them from maybe an onClick event or a button, or maybe programmatically whenever you do some, whenever you get some information from an API or from some other data source.

5. Creating Custom Hooks in React

Short description:

To demonstrate creating your own hooks in React, I've provided a code sandbox with examples. The examples show how to use the context API with local state. By combining useState, useContext, and setContext, you can create a small, efficient local state management tool. When creating a hook in React, you're essentially following the standard of creating a function and appending it with 'use'. The hook example in the code sandbox extends the useContext hook from React and returns values from the context. This allows you to create your own hooks for handling context and accessing values from the context without needing to import the context object in every component. The code sandbox provides examples of how to create and extend your own hooks for different use cases, such as data fetching and other side effects.

And for this, you can also create your own hooks in order to handle this. And to demonstrate this, let me open up a code sandbox for you. Code sandbox. I have some React examples here. Yes. So in here you can see, I've just simple context burning and let me go to my index file. And here, now I'll also share it in the chats, or maybe it's easier in the Discord channel. The code sandbox link, there we go. Yeah. So in here I've created a small example of using the context API with local state. And in here we can just refresh it to look the console warnings. You can see we have, well, just a simple counter with a button and it's the same code we just saw on my screen. So let me go here. Yeah, so what we're seeing here is just react. So I've imported react. You don't have to do that actually in later versions but it's, yeah, it doesn't break your code. And I'm also importing new states and create context. So what I'm doing here is actually creating a context value, context object using create context, and then I have my components, which is actually a place where I put my provider and in there I put local state, so count and set count. And then I pass second component into this, which is this one. And that's the one that's actually consuming this. And I also put it on this, maybe a bit more cleaner. This and then the second component, which is wrapped inside my provider. I'm able to actually get values from the context because what I'm doing here is using the use context hook and it could also restructure this if I want, so count, set count. Whatever I'm doing here is whenever I do the onclick event, I'll be using a value from a use context, which is set count to replace the state variable for counts. So this is just React and it's just combining use state, use context and set context in order to create a small, efficient local state management tool. Okay, some issues here. It's probably related to something else. But yeah, as you can see, it's quite straightforward. I also shared the link in the discord channel. So make sure to have a look and try it out yourself. But what I was getting to is, if you're doing this and you're separating concerns, you're also creating your own provider components. You can also create your own hooks to handle this. And creating a hook in React is probably sounding a bit more complex than it actually is. Cause creating a hook is, it's actually not really creating a hook, it's just following the standard to create a hook, which is also having a function. Ideally a pure function and append it with use. So whatever you put in there, use something behind it, you're using camel casing, then you're already creating a hook in React. So it's just as simple as that. So just as simple as that. On the left side you can see an example of such a hook and you can see here that I'm also extending or, yeah, I think extending is the best word, to use context hook from React. So whenever you're creating own hook in React, usually you're also extending existing hooks. And you can see here that our use context hook is returning values from our context. And this is something you will do like in this scenario, but maybe doesn't make that much sense because we're not changing any of the values in our context. But usually it would be also maybe changing values from your context, maybe you're combining multiple contexts together and it really makes sense to create your own hook and able to use this. And another nice advantages that you don't need to import your context object in every component that is using context, but you only have to import it inside the hook that you created yourself. So that hook is using, use context in order to mutate or get value from context. So on the right you can see, well, how you can actually use such a context hook in order to use values from the context. And it's almost the same as you would see with any other hook, you're just using your own custom hook in order to get values from a different React hook that you might have alterated or simplified or maybe you've extended them in any way. And this is something you can also see in, well, in the examples in the encode sandbox, you can see here how you can create such a hook yourself and how you can extend it. So maybe in here you could have done data fetching, other side effects you might be doing there. So these are all things you could do in there.

6. Combining Contexts and Using useMemo Hook

Short description:

Combining multiple contexts is a nice way to combine things from multiple sources. The useMemo hook can be used with the Context API to memoize values and prevent unnecessary rerenders. By adding the useMemo hook to the provider, you can ensure that the context value only changes when the dependent value changes. This prevents components from rerendering when their context value remains the same. Memoization can be demonstrated with an example in a code sandbox.

I think it's best always to keep these things pure because you want to know what goes in and what goes out. But maybe something else you could be doing here is combining multiple contexts. So this could be maybe my second context in case you had any. So it's also a nice way to combine things from multiple ways.

And something else that's nice, that I will tell you a bit more about is also using context together with the use-memo hook. And the use-memo hook is a hook you can use to memoise values. You might have heard about how to memoise React components, but you can do the same things for the Context API and also the values you pass to the Context API. So what does it look like? So usually whenever you have a context, it's the same as with local state. If you have local state in your parent component and you pass it down to children components, whenever you change something in your local state, all the children components will rerender. And it's the same with context. So if you have context value, you wrap components with it. These components are using something from your context. Context changes, then of course, these components will try to rerender. And with context, it could be the case that it also happens that components rerender when they actually don't need to rerender, because maybe the context value that they're using isn't actually being updated. So that's why it's important to also look if you need to use the useMemoHook, because you don't want updates in one part of your component tree to update components, or actually not really update, but rerender components somewhere else in its component tree when actually nothing changed for that component. So that's where the useMemoHook steps in.

And useMemoHook is something that you can add to your provider. So we have just a simple provider here. It's taking counts and an update function for counts from a localStateHook. So the useStateHook. And before we're passing this value to our provider, we're actually using the useMemoHook to memoize this value. And if you already saw to useEffectHook, you're probably familiar with the dependency array. Also, the useMemoHook has a dependency array. So using the dependency array, it will only update the value through the useMemoHook whenever the value for count changes. So if someone is using the updateCount function, I think functions are a better way to check for also in the dependency arrays because often they're not being compared in a great way. So it's always best to take values like a count, which is just a string or an integer because those things are easily being compared. But if you look at this one, you can see that the context provider value will only change whenever count will change. So if nothing changes to count, then there should be no reason for the provider or the context in this case to update. And this will also make sure that no components that are using this value are being updated unless the actual count value changes. So not if someone does something with the update count function or it would get paused, it would get called, it would get voided, this is function on one because that's why you used to use memo. Also, let me show you an example of this. Let me get back to here. So let me get back to the code sandbox. And here I can show you an example about what it looks like with the memo. The console for this. First, the app, clear the console. Oh. Yes. So whenever my application first renders, and it's something you can see. Actually, two components get rendered, right? So the entire app component, which is basically everything you'll see on this page, and also the component. And the component is basically this. So let me first do this without the memoized value. So whenever my component renders, you can see app renders, and component renders. And app is the entire application, which is everything you'll see. And component is just the part with the count and the button. So whenever I render the app, of course, app and component renders again. But when I'm updating context, just context changes, which is actually fine. Whenever I'm rendering app, my component also renders. Well, actually nothing changed for my component because count is still the same, but still, I'm rendering my app, and this component gets rendered. So by memoizing it, you can actually prevent this from happening.

7. Preventing Unnecessary Component Rerenders

Short description:

You can prevent unnecessary component re-renders by separating provider logic from consumers and keeping providers small.

So I'm just updating context. So you can also re-render my app without having my component being re-rendered because context is wrapping everything, and rendering my app shouldn't re-render this component because nothing changed in here. The count is still seven. I didn't change my context value because when I do app component renders, but when I don't change it, actually only app should render. So this is not the case in the first time because the first time we don't have a count, easily update, then both. But if you don't memoize this value, like this, then actually you will see whenever I render my application, every time it will also render my components, which could be strange, and it's something you try to avoid, and usually React is very good in avoiding this for you. But there are always edge cases and cases where they aren't. And you can actually prevent this from happening a lot by really just separating provider logic from consumers. So that's an important thing to do. And also by keeping providers small. So if you keep providers small, then there is a smaller chance that you're unnecessarily updating things.

8. Complex Logic and useReducerHook

Short description:

In React, you can use the useReducerHook for more complex logic. It returns the current state and a dispatch function to update the state based on a reducer function. The reducer function takes the current state and the dispatched input, returning a new state. This allows for more efficient and controlled state management.

So what if I have more complex logic? We briefly touched this point already. So in React, whenever you're creating state, you have a useStateHook, which is for a very simple local state, but you also have a useReducerHook. And the useReducerHook is a bit more complex because it detects two variables, which is the reducer initial state and it returns an array consisting of state and a dispatch function. So whatever it returns for state is actually the current state. And whenever you just mount your application, run it for the first time, the current state will probably be equal to the initial state that you feed to the useReducerHook. But it also returns a dispatch function. And the dispatch function can be used to update states. And how to update states will then determine on the reducer function. So your reducer function is a function that takes the current state, sometimes also take the initial state, but it takes the current state and based on the current state and whatever you dispatch. So whatever input you give to the dispatch function, it will return the new state. So these are important concepts to remember. So we have to use reducer hook. It takes two things, the reducer to return a new state and also the initial state. And it returns the current state often equal to the initial state and also a function to update the state which calls the reducer, which will then create a new state.

9. Using Reducer in Context API

Short description:

The reducer function in the Context API is similar to Redux. It takes the current state and an action, and based on the action type, it updates the state. You can use the useReducer hook to create a state and dispatch function. Pass these to the Context provider, and you can access and update the state from any component in the tree. Dispatch functions allow you to update the state by calling them. Debugging can be done by logging or wrapping dispatch functions with custom hooks. The Context API provides a more efficient and familiar way to manage state in React applications.

So what does this look like? So your reducer function will probably look something like this. So it's a function that takes the current states and the action and the action is, well, something I use this naming because I'm familiar with Redux. And Redux is based on actions. So it takes two things, it takes current state and also the action or whatever you put in your dispatch function. And based on whatever you put in your action, it's, which is, whatever you put in your dispatch function, it'll do something with state. So in case in your dispatch function, you provide this object, which has a type and a payload, which is very similar to Redux. And that's why I chose for the setup because I've been working with Redux for a longer time. So based, whatever I put in my dispatch function, which is a type increase. It'll do something with my current state based on whatever I've also put in my dispatch functions. So a payload. And based on this, it returns a new state. So the new state will be the count, the new count, which is the current count. And also, it's summed up the count that we have from our dispatch function. And also, it's, yeah, it takes the current state and it will do something with your current state. And again, I already mentioned Redux a couple of times. It can all look very familiar because Redux, typically a reducer in Redux will look something like this. So you would have an initial state, you would have an action. Based on your action type, you would do something and you will mutate state. So I took a lot of concepts that you have in Redux to make it more familiar, but also because Redux in general is set up quite efficiently. These are concepts you can still use with the Context API, but you no longer have to use Redux. Or you can use it together with Context. And if you want to use it together with Context, you of course need to create an initial state and a reducer, you pass it to a useReducer hook, it returns the current state and Dispatch Function. And those are things you would pass to your Context. So in your Context, you would have a value, which is basically the state that comes from a useReducer hook. And also functionalities that are called the Dispatch Function. So again, this looks very similar to what we did with the local, with the useState hook, but now it's a bit more complex and also a bit more efficient because we're really using Context Provider now to actually expose our state from the useReducer hook to our entire component tree. And if you want to update the value from the Context, you can just call the decreaseContext or increaseContext function, which on their end are called Dispatch Functions from the useReducer hook. And this is something I can again show you if we go back to the code sandbox. We would go here, we would have from Context with Reducer. That's probably the one. So in here you can see we have a bit more complex setup so we can increaseContext, we can decreaseContext. And whenever I push one of these values, it will actually dispatch a function for my useReducer hook, which is something you can see in here. So again, I have a ContextProvider, I have an initial state, I have a Reducer Function, and both I will pass to the useReducer hook. That on their end will do something with these values. Okay. And in my ContextProvider, I have set it to value for my Reducer state, that's the value for my context. And also I've put the Dispatch Functions, which are wrapped in a different function. So this is also why it's good to separate provider context, provider logic from your actual consumer because in here you can actually dispatch things. Maybe you can have side effects, maybe you can dispatch and then based on whatever comes back, you can take different actions. So these are things you can do in your ContextProvider. And again, here you can see from your component, which is consuming the context, you can just use a UseContextHook or you can create your own hook, which we saw before, which you'll also do in the exercises later on. So this component here is, yeah, being able to click functions that are coming from the context. And based on that, it will do something with the context value. So it will either increase or decrease it. So just as easy as that.

10. Debugging with Redux and Creating Custom Hooks

Short description:

Redux comes with a lot of functions for debugging, while the context API does not. However, you can use console logs or console tables and wrap your dispatch functions with other functions to create your own debugging hooks. By calling the useReducer hook with logs, you can have a dispatch function that allows for logging. The code sandbox example demonstrates this by logging actions in the form of a table.

So what about debugging? So one of the nice things about Redux that it comes with a lot of functions for debugging. So unfortunately, the context API has now built in debugging, but of course you could use a simple console log or console table things, and also wrap your dispatch functions with other functions. So you could easily create your own hook, having not really having useReducer, but creating and extending with your own hook, having usedReducer with logs, and then just extending your dispatch function with something that logs it. And then from you as a consumer from this API or from this application, you could just call the useReducer with logs from a hook instead of the useReducer hook, and to already have a dispatch function that allows for logging. That looks like something you can see on this example. So make sure to go to the code sandbox and see what it will look like in order to really use this. And this one is a component that's rendered. You can actually see that every time we do something, it'll actually log what happened. So this is a console.table. Not too many people know about it, but you can actually log things in the form of a table instead of just logs. Actually, a quite nice feature of JavaScript.

11. Creating Global Context for State Management

Short description:

To have a global context for state management in your application, you can separate providers into different components. This allows you to have providers for specific contexts, such as products, categories, and cart. By wrapping these context providers with a global context, you can access information from any component in your application. This setup enables efficient state management and is further explained in the exercises.

So what if you want a global context? Because that's probably also what you would need if you really want to have state management for your application. You would also want a global context. And you can do this by, again, separating concern from your providers into different provider components. And here you can see, we can recreate different providers per category. So this could be an e-commerce application. Maybe you would have a provider for products context, you have one for categories context, you have one for your cart or for any other checkout progress. And then you would have a global context which is actually wrapping all these different context providers. And your global context, you can export it, you can pass children components to it. And then maybe when you set up your application and you're using something like React router, you can have the global context wrap your entire application. So this could be the setup that you actually be using here. You can actually have to global context have it wrap your entire routing. And then from any component, like products or products detail, you're able to actually get information for both the products context and also from the categories context. And then from any components, you're basically able to get the information something. Okay. In a similar fashion like we're doing here. But more about this because this is something you also see in the exercises.

12. Summary, Exercises, and Breakout Rooms

Short description:

Context can be used to pass data to the component tree. Hooks like useContext, useState, and useReducer can be used to access and update the context value. Context is not a solution for every state problem, but it can be used for local cache, teaming, component libraries, and application state. The workshop will include exercises on GitHub where you can practice using context in an isolated environment. You will be put in breakout rooms with other participants to work on the exercises. Check the provided link for the repository and clone it to get started. There are 11 exercises available, with additional bonuses. If you have questions, save them for the breakout room discussion.

So to summarize, you can use context to pass data to the component tree. And you can also use hooks for this. So it's so that you easily access this context from anywhere in a component tree. So you can use a use context loop to get values from context. You can also use a useState or useReducer hook to actually give value to the context. And also, it's important to understand context is not a solution for every state problem. So context can be a solution for your state. But it can also be used in different ways. You will see people using it for sort of local cache. You see other people using it for teaming, for maybe component libraries. But you also see people using it for states and even global state, not really global state because global would imply you can use it anywhere, but more like application state. So I would say global state is something you share with an API, and global state application state would be something just for API. So context could definitely be a solution for that.

And if you want to learn more about this, be using the rest of the workshop to create exercises for which I'll put you in breakout rooms, I would also make sure to find the code sandbox link here and also find it in the Discord channel. So you actually be able to play around with the context in an isolated solution, isolated place. And then in the exercises, I will show you how to actually do this more in detail. So the exercise we will be going to my GitHub, in which you can find all the repositories that I work on. And React Context Hook is not the one. It is the React Context Hook workshop one. So I will also share the link with you in the Discord channel. I will also share it here in the chat. I can find it. Let's see. Okay.

So what we'll be doing now is I will first show you more about the GitHub repository. Then I can take maybe five minutes to answer questions from the chat. And then I'll put you all in breakout rooms. Let me see how many people we've got right now. Zoom. It's nice how easily you can lose things if you have too much going on in your screens. So the Zoom is somewhere here. I'll see here. So we have 58 participants, that we're putting you in, I think, 10 different breakout rooms in which you'll be then with four or five people. Maybe six to work on the exercises. And then I will regularly check in with everyone to see how you're doing. But for now, I'll show you how to set up this one. So you would be going to the exercises link which I also showed in the chat. And in here, you can just as easily, you can go just anywhere. So I usually keep my codes in this directory because I used to be using Atom as my browser, not browser ID. So in there you would just do git clone and put in a repositor URL and it will be set up. And then you can just do yarn and yarn start and it will install everything in order to do the exercises. Any exercises are listed down here and there are 11 in total but also some bonuses. So I don't expect you to be able to do everything today unless you're really fast and maybe we are really fast and that would be great. But if not, then we still have the Discord channel to discuss later on. With that said, make sure to go to this repository and clone it. So you would have a local version of all the exercises and in here, all the code can be found. And also it will be using an API which is being fed by this one. So it's using a local API. So it's not that complex but make sure to get it running. And if you don't get it running, please don't use the chat now to ask questions but wait until you're in a breakout room so you can ask the questions to a smaller group.

QnA

Answering Questions and Breakout Rooms

Short description:

Let me go to the chat and see if I can answer some questions. I see people are asking about other things for state management, sharing the code sandbox, which is good. How do we avoid having many different providers? Would you pass down dispatchers and then exporting action creators? It's something that's nice if you have a bigger application. If you have a smaller one, maybe you shouldn't do that. Ideally, it would be nice to really create action creators. We also have questions in Discord. I will try to answer them in there as well. For now, I will be putting you in breakout rooms, but also make sure to give yourself a short break.

Let me go to the chat and see if I can answer some questions. Yeah, I'm about to start an editor with Atem in these but I haven't been using it for a long time. So I think it was my first real ID when I finally got rid of Notepad+++. So good times in the past. Let me see if I can find some questions to answer. I see people are asking about other things for state management, sharing the code sandbox, which is good. So how do we avoid having many different providers? Yeah, so I think these are questions like would you pass down dispatchers and then exporting action creators? It's something that's nice if you have a bigger application. If you have a smaller one, maybe you shouldn't do that. But it wouldn't matter that much. I think it also determines a bit how you want to structure things and how you work together as a team. And also what's your starting point. I think it would be fine to just start out by passing along dispatcher function. But yeah, ideally, it would be nice to really create action creators. So, yeah, we also have questions in Discord. I will try to answer them in there as well. So for now I will be putting you in breakout rooms, but also you've been listening for me for about an hour. So also make sure to give yourself a short break. So let me create a breakout room. First of sharing my screen.

Q&A on Fetching Reviews and Implementing Solutions

Short description:

In the Q&A session, the speaker discusses the pros and cons of fetching all reviews and selecting the ones associated with a specific hotel versus fetching reviews directly for that hotel. They mention that it's important to avoid fetching unnecessary data and suggest organizing the data fetching logic inside the context but triggering the data fetching function from the component that uses the data. Performance considerations are also highlighted, as fetching excessive data and not setting proper boundaries can lead to performance issues. The speaker then addresses a specific question about implementing a solution for fetching hotel reviews from a REST API, explaining the use of the useEffect hook and separate user factors for different effects.

Hello, so how did everyone do in the exercises? I thought it was good to spend the last 15 or 20 minutes we have together on some Q and A. So if you have any questions or maybe some exercises that people already got stuck at, then we can spend this time to have a look at it. So feel free to unmute yourself or use the chat if you have any questions or have specific exercises that you want to discuss.

So my question is a bit of a refactoring question. So in the reviews context, you either can get all the reviews and then can for each hotel, you can select the list of reviews that are associated with this hotel, or you can fetch the reviews directly for this hotel. There are bits of pros and cons between the two of them. And I know it's not the scope of this session, but do you think there's a performance issue or a solution might be better than the other?

Yeah, so there are multiple ways to handle this. So you need to make sure that you never fetch data that you're not gonna use. I think that's one for starters. So what you can do and what we also showed in, I don't know which question it was, which you did in question eight. Or maybe you already did it before. And so at least in the question, so I don't know if everyone knew, but there is also different branches for every solution. So that's something you could, if you've got stuck, you can have a look at it. But if I leave maybe in exercise five here. No, maybe someone else knows. But there are so many solution exercises where the data fetching logic is inside the context, but the function to start fetching the data is in the component that is using the data. So that will make sure that you don't fetch data that you're not using, because it's something you want to avoid. I think in general, you never want to start data fetching from a different component if you're not triggered with a function and the component that's using the data. Because it gets very confusing otherwise. Yeah. I don't know if that answers your question. Yeah, yeah. Thank you. But it is something, yeah, so performance is something to think about when using context, because, yeah, if you don't split things up correctly, then you would end up in a situation where you would get performance issues because you fetch a lot of data, you bring together a lot of stuff. And also React will re-render if you change something in context unless you set proper boundaries. So it is something to think about indeed.

Can you show your screen and go over your solution to see how you did it? What do you mean? If you can go through the solution and explain, you know, we did it, but explain clearly why you did it. For which question? I can do it, but then you need to let me know which questions. Oh, sorry. Question three and four, maybe. Okay. Question three or four. Yeah, definitely. Yes, so question three and four. So question three was about get the reviews from the hotel, from the rest API. Yeah, so let me see, where's the terminal. French. Okay, so for question three, we contribute for this hotel, so you can note those screen was in detail. So there's some styling here, which you can ignore. So this one was still two parts. So I want us to use effect to get the data for the hotel. So guess for hotel, which would also only need to get if the match parents ID is set. So this is if you have HTTP localhost 3000, slash hotel, slash one. So here one is match that parents with ID. And basically the first user factor. And then it's the second user factor based on the hotel ID to get to reviews and it also has its own local state. So typically you want to have different user factor for different effects. Cause every side effect should have its own user factor because then you can easily separate concerns. So in this scenario, what you could have done is indeed have the same one because they're both using match parents ID but in case maybe match parents ID is undefined or something, then you don't want to have them in the same thing. And maybe also this is an ID that doesn't exist.

Separating Concerns and Using Context

Short description:

When creating a context, separate concerns and provide fetch functions for each concern. Create a context provider using createContext and set a provider for the specific concern. Use the context to access values previously obtained from local state. Copy the logic from the component to the context, making the component simpler and easier to refactor. Pass the data fetching function to the context and use it in the component with a useEffect hook to fetch data when needed. The context will update the values based on the fetched data.

So people could just put crazy shit in here. Like maybe this. It probably isn't ID you can find in the REST API. So that's why it's better to separate the concerns. And then they both have their own fetch function. They both set reviews for the review and this one will set hotel. And this logic is something you also could have put in maybe a different look, or at least the data fetching because it's mostly the same, but the results are different. But that's about question three.

Question four, let me check. Yeah, so in four, it will get interesting because here we're creating a context. So what you should have done for this one, hotelsContext, so it's probably in hotels. Yes, you would create a context here using the createContext method. Then we create a context provider, which is using the hotelsContext which we created here to set a provider. And if they're a certain provider, they come from local state. So it's loading error in hotels. So basically what I did, these things are previously here, all these things, basically all this. So before this was here, it was in the hotels component. So I set my local state, I did my data fetching, and based on that, I will use these values here. But now instead, what I'm gonna do is create a context for it, so you could delete all this. You create a context file, you set the local state in here. So it's just like copy-paste, you do the data fetching, and the results for this is you don't display them, but instead you put them in a context. So they also become context values, and our context is something we export. So in hotels, we can import the hotels context. And in front of context, we can get loading errors in hotels, which previously we got from local state, but now we get them from the context, and the context gets them from local state. Basically, we just copied a lot of logic from a hotels component to the context, making this component more dumb, and also easier to refactor and to replace, and having the context have all the logic in there.

But what I was mentioning before is, what you actually don't want to do is this. So the use effect is actually something you don't want to do in here. So later on, in one of the exercises further along, it will be shown that to fetch the data, what you actually want to be doing is also passing this function here. So you want to have the data fetching function in your context, and then from here, you just do this, so fetch data, and then you would have a use effect hook. Dependency array could be empty. It could be hotels.length is zero in the beginning, or actually non-existing, so thank you, editor. And then fetch data. Actually what you want to do is this. So... So what it does, so the context has a logic to fetch the data, but your component decides when it will be fetched. So in your use effect hook, you will decide you want to fetch the data. Whenever you fetch the data, we call this function from the context. Oh, not that one. Context. In the context, this function will be called, and when it will be called, it will set the hotels, it will set loading to false, and it will set error to true in case of an error. And then the context will be updated. So hotels will change. First it will be, so first... Or initial render actually. So initial render... Is this one. And then after we set the data fetching, hotels will be... Some array with data. So something like this. Did that answer your question? Yes, thank you.

Managing Errors with Context

Short description:

Managing errors with context depends on the type of error and how you want to handle it. Data fetching errors can be put on the context value, making it easier to identify the error later. Each context can have its own errors, allowing you to decide whether to have global errors or errors specific to different parts of the context. It depends on what you want to display to your users. If you want to show specific errors for each field, you can have an error per field. If you prefer a global error, you can have a global error per context. The choice depends on your specific use case and what you want to communicate to your users.

Okay, good. Yes, do you have a question, Paolo? Yeah, sorry. I think it's a general question but I think I don't understand what is the best way to manage the errors with a context. I think it's so difficult for me to understand what is the best way to do this. Yeah, so it really depends on what kind of error and how you want to scope your error. So if it's a data fetching error, you could put the error on the context value. Do you have other kinds of... I don't know, what kind of errors are we talking about? Yeah, for example, in this way when we can add hotels to the list and for example some fetch was failing with the hotel list, for example, something like that. Okay, yeah, I would just put them on a context and then, so if you have a use-reducer later on, it will be easier to see what is going on and what's the actual error. Oh no, I'm talking about, for example, the estate of error and set error in the catch but I think that in some projects could be some difficult for understand what is the best way to maintain the errors or for example, if we have different list of data and we have different kinds of errors. Yeah, so every context would be specifies to a certain things, you would have a context for review, a context for hotel and every context can have its own errors. And I think there you should decide if you want to have errors for everything that goes wrong, if you want to have like a global error, that's also something you can do. But I think it's more of a general state management question. So what kind of errors do you want to put in there? I think it's also up to the side, like what do you want to display to your users. So if you want to show your users there's an error and that's it. And you can just have like a global error per context. If you want to show your users what's going on, then you could have an error per part of the context. So if you want to show your users, I don't know, maybe an email should be, an input field should be filled and also they should fill something else and they should fill all the things. Now you could also have specify your context, like you have an input field for email, an input field for name, an input field for a body and then have an error per field or just have the global error. So it really depends on what you want to display. So context, what you put in there should really be what you also use to display to users. So if you don't want to display, breaking down errors, then you shouldn't have to do it, if you want to do that, now you can just use the context for it. Does that make sense? Yeah, it makes sense. Yeah, it is the question. If it's better, for example, have different contexts to do this, for example, a global context and refresh this global context if we need. Okay. Cool.

Watch more workshops on 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

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!
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
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 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 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.