This course has been updated! We now recommend you take the React Performance course.

Check out a free preview of the full State Management in Pure React, v2 course:
The "Context Practice" Lesson is part of the full, State Management in Pure React, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve demonstrates how to use the context API to create and delete new states, and talks about the trade offs that are direct results of switching to the context API.

Get Unlimited Access Now

Transcript from the "Context Practice" Lesson

>> Our mission was to no longer need the props and to be able to hook into the contexts to get the ability to add a new grudge. So we can start by burning the boats and just get rid of that. Now keep in mind, this react memo is probably causing more harm than good.

[00:00:12] We're not gonna do anything about it. But we're just going to call it out, the fact of the matter is like this is going to rerender because it's hooking into every time that context object changes. And there's crazy stuff you could do, like you could separate out dispatch to one context and the state and another, and only hook, it's not worth it.

[00:00:28] Again, like wait until you actually have a real performance problem before you start overengineering. The whole idea is to make things less complex. So we removed that. And now we just need to get access to addGrudge. So we'll say const addGrudge = React.useContext, And now we swap this out over here.

[00:01:00] And that should do the trick, let's find out together. And it's added to the page. All right, so let's just take a look at that application component one more time. And I showed it to you, but I just wanna point it out. From all of the complication that we had when we started with the use state and the beginning state of this application where it was managing all of it, now it is simply, okay, what does it mean to be this application?

[00:01:24] What are those pieces? And those pieces can hook into what they need to. Now we can begin to move stuff around. And this is really great when you're prototyping too, because you can basically do large-scale refactors of the layout of the application and not necessarily worry about all these props getting passed through, right?

[00:01:39] If we wanted the new grudge form to be at the bottom or to be inside of grudges, I just move it there. And it takes all of the state management with it. But like I said, we noticed that there were some trade offs. So let's just talk about it real quick and understand what we gained and what we lost.

[00:01:57] We did lose those performance optimizations that we got with using useCallback on the dispatch. Was it the right choice? It's a tradeoff. I argue that unless you are actually solving a performance problem that exists, maintainability and the ability to actually add features and be able to do refactoring is way more important.

[00:02:20] And I would say that, yeah, this is a very small example, but there might be even a tiny microcosm in your application where you use this. Do you need to always wrap the entire application component? No, right? But if you had a bunch of components where it's getting a little squirrely, you might go around the kind of highest level of that, move that into a context, and have the ability to kind of move stuff around even in that smaller part of your application.

[00:02:43] Right? Like Joe asked me, does this replace it for Redux? You might use Redux for all the state management, but if there is some filtering that you wanna show in two different places, right, that might still go to the context API. You can use the Context API for some of that ephemeral state as well, right?

[00:02:57] Ascending, descending, that might matter in different places, right? And so if you need it in two different parts of the tree, it feels weird put that in Redux, right? But it might make total sense too, because even with Redux, like we end up with a lot of that boilerplate around like connect and stuff like that.

[00:03:12] It might make sense to use them kind of interchangeably as well. And like I said, this will work really well for even that larger tree that we saw, right? And so the idea that anything could hook in to stuff at the top level cleans up our code a lot.

[00:03:26] So it's worth thinking about the trade-offs. Depending on the situation, if the performance is meaningful, then no, it's not the right choice for you. But if it is not, if you're measuring, right? And you can see that it's not really affecting performance, then having maintainability is totally worth it.