Validate use of Context using a custom hook and the useContext React hook
What happens if the user of a component that uses the Context api and the useContext hook to define its compound components, renders one of its components outside of the context provider? If this happened, an error would be thrown since the component will not be able to access the values of the context provided by the parent component.
There are two options to solve this problem, one is to use default values and the other is to create a validation strategy. We can use a custom hook to encapsulate the necessary logic to retrieve and validate the context values and share it between the different compound components.
Instructor: [0:00] Our component uses the Context API and the useContext hook to define our compound component and share the state, but what will happen if the user render one of the compound components outside of the main component? We can check it by simply moving it, one of these components, outside of the main component.
[0:19] We will see an error message stating that it's not possible to read the activePageIndex property from undefined. This is because our WizardPages components tries to access the activ PageIndex using destructuring from the useContext hook that reads the values from the closest upstream provider in three. As there is no provider, the error is issue.
[0:43] One way to work around this problem is to use the full values for the context attributes. We find activePageIndex to be zero, and the two functions goNextPage and goPrevPage are defined as non-operational functions. This avoids the error, but the component doesn't work as expected.
[1:01] Another strategy that we can use is add a validation step and issue an error message. For this, we will create a function called useWizardContext that will encompass the use of the useContext hook.
[1:15] Indeed, here we are creating a custom hook. First, we will make use of the context by using the useContext hook reading the WizardContext that will return a complete object with the value of the context.
[1:30] Now, with a simple conditional block using if, we can check if the context is null or not. If it's null, we issue an error indicating that the compound component cannot be rendered outside of the barium with our component. Otherwise, the context is simple return. It only remains to use this new hook. For that, we replaced all the calls to useContext with our new hook, and we can see the new error message.
[1:57] In summary, we have used a custom hook to encapsulate logic necessary to validate compound components that use a WizardContext is actually rendered within the tree, created by the context provider. For these, we check if the context value is defined. If it's not, we issue an error message.
[2:16] Another strategy is to provide default values to the context attributes, but sometimes, this does not make sense as it hides the real problem.
Never seen the pattern before (Wizard.Pages) where could I read more about it?