Provider Component

[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.

[00:00] So we've got another interesting issue. If we record this, and I change something about the footer and Kodi, then stop that. We're going to have a bunch of renders for the typing Kodi. But you'll notice that we're re-rendering main and we're re-rendering app, even though those don't care

[00:16] about the name and the footer. That's external to those things. They shouldn't have to re-render in that case. And so we're going to be creating a provider component, so a component that's responsible for rendering the context. This is actually one of those optimizations that people just do naturally. It's pretty normal to create a provider component,

[00:36] but I thought it was useful to have a step here to explain that that actually is a performance improvement when you can do that, because it means that changes to the context value do not necessarily re-render the children of the context. So let's take a look at what that does.

Diagnose, profile, and fix performance problems in your React application using the Browser Profiler, React DevTools Profiler, and optimization techniques.

React Performance

React Fundamentals

React Hooks

Advanced React APIs

React Suspense

Advanced React Patterns

React Server Components

Epic React Pro

React Performance Intro

Intro to Element Optimization

Reusing Elements

Element Props

Context

Memoize Elements

Memoize Components

Dad Joke Break Element Optimization

Element Optimization

Intro to Optimize Context

Memoize Context

Split Context

Dad Joke Break Optimize Context

Optimize Context

Concurrent Rendering Intro

useDeferredValue + memo

Dad Joke Break Concurrent Rendering

Concurrent Rendering

Intro to Code Splitting

lazy

Eager Loading

Transitions

Dad Joke Break Code Splitting

Code Splitting

Intro to Expensive Calculations

useMemo

Web Worker

Async Results

Dad Joke Break Expensive Calculations

Expensive Calculations

Intro to Optimize Rendering

Component Memoization

Custom Comparator

Primitives

Dad Joke Break Optimize Rendering

Optimize Rendering

Intro to Windowing

Virtualizer

Dad Joke Break Windowing

Windowing

Outro to React Performance

React Performance

React Performance

Transcript

Provider Component

Transcript