00:00 So for us to move everything into a provider component, we're going to need to move all of our state management up to that as well. So let's start by making the provider component function, footer provider, and this is going to need to take children, so we can render the children for this provider, and then we're going to return

00:19 the footer context without the dot provider, and our value is going to come from what we have down here. So we're just going to take that step right there, come up here and say our value is there. One other thing that we're going to want to do is we're no longer

00:37 going to be passing the set color and set name as props, like we're doing down here. Right here, we're not going to pass those props because the footer setters is going to access it through the context provider. So let's get rid of all of this stuff,

00:53 and we'll change this from footer context to footer provider, we'll get rid of these props, we'll get rid of this, and then we'll come up here and add set color to that, and set name, there we go,

01:11 to that so that we can include those in our provider, set color, set name, and you'll notice that our ESLint rule isn't telling us we need to include those in our dependency array. It's also not going to tell us to not include it in the dependency array. It's fine either way because the useState hook is going to

01:29 return us a function that is stable across renders. It's going to be the same forever, so it doesn't make a difference whether you include it or not. So I typically don't bother including it because it doesn't make a difference either way, and if anything, it's just one less thing for React to have to check, are these things equal? So it really isn't that big of a deal,

01:48 but I typically exclude those if I can. Great. So then my footer setters is still expecting to get those via props, but it's no longer getting it via props, it's getting it via the context. So let's get that from useFooter, and that should have us in a good situation.

02:08 So if I clear this out and then do this again and change this, some context value, you notice our footer re-renders properly. Our footer setters was going to re-render because it's consuming the context. The context provider will re-render, and the footer provider itself, that component re-renders because hook changed,

02:28 but we're not seeing the app or main components in here, and the reason is because this app component is no longer managing the state that is changing that's inside the footer provider, and the main component doesn't re-render because it's actually kind of interesting.

02:46 It's another React not re-rendering the same React elements that it received before. So if we look at the footer provider, it's receiving all of this stuff as children. Dive into that, and we have children. When all of this re-runs, the children are not changed. That's exactly the same as it was before,

03:04 and so we don't have to worry about re-rendering or calling all of those functions again or anything because the children remain the same between these, and so this is why having a provider component like this is actually a performance improvement because it allows React to make changes to this component.

03:24 We make some update to our provider's state, and React is able to just say, oh, the children didn't change. I'm not gonna bother calling any of those functions. Composition, again, my friends, it is a good thing, not only for our ability to write a UI

03:42 that seems to make sense, but also because the optimizations that React can do because of that level of composition. So there you go. That's an improvement there.