Instructor: One thing we need to consider when using React to create context is what would happen if somebody renders a consumer outside of a provider. We can do that inside of here by swapping out our toggle with a div, and a div here.
We're going to get an error, "Cannot read on of undefined." That's happening because here, we're destructuring something that is actually undefined. The context value here is not defined because we're not providing any sort of default value, and we're not providing a value via a provider.
We could solve this problem in two ways. First, we can provide a default value here -- provide on is false, and toggle is just an empty arrow function. That would avoid the error, but the component doesn't work at all, so we'll just use some validation.
I'm going to make a new component called function toggle consumer. That's going to take some props, and then this is going to return toggle context consumer.
As the child function, it's going to get the context, and it's going to return props.childrencontext.
So far, we haven't done anything different. Let's just swap out all of these for our new function, and everything works exactly the same as it had before.
Now let's do our validation. We'll say, "If there's not context, then that means that we're rendering this outside of a provider."
That's not allowed, so we'll throw a new error that says, "Toggle compound components must be rendered within the toggle component." With that, we get a useful and actionable error message. Let's go ahead and fix this to be toggle again, and the button is still working.
In review, the problem we're trying to solve here is that the toggle context consumer in our situation doesn't make sense to be rendered outside of the toggle context provider, so we're adding some validation to make sure that the context value does exist.
If it doesn't, we'll throw an error. That ensures that people are rendering the toggle context consumer within the toggle context provider.
There are some situations where having a default value for a context does make sense, but for compound components, that generally isn't the case. Having some form of validation can help users of your compound components avoid confusing errors.