Learn how to solve issues that arise from overusing "prop drilling" using React Context.

React Context

In the last exercise, you learned how to create a React context object. You also learned how to assign the context's `.Provider` component a `value` prop so descendants can access that value. Now, let's advance our understanding. What if our application requires the same context in multiple areas, each with a distinct value? Think of varying themes across different application sections.

A `.Provider` component may be reused with the same context multiple times in an application with different values. This is useful if the context is rendered by a component that is used multiple times throughout the application. Each instance of the component might want to give a different value to the context. For example, a component might render two `.Provider` components that each receive a different value:

```js
const GreetingContext = React.createContext();

const ChildComponent = () => {
  const greeting = useContext(GreetingContext);
  return <h2>{greeting}</h2>
}

const MyComponent = () => {
  return (
    <>
      <GreetingContext.Provider value="bonjour le monde!">
        <ChildComponent />
      </GreetingContext.Provider>
      <GreetingContext.Provider value="hallo welt!">
        <ChildComponent />
      </GreetingContext.Provider>
    </>
  );
};
```

To practice this concept, let's refactor our application. We'll configure the `ThemeContext` so that each time its `.Provider` component is used for different contact sections, it's given a distinct `value` prop.

Multiple Providers

It's time to explore how we can efficiently share data across our application and eliminate prop drilling using the Context API. 

Through a **Provider** and **Consumer** pattern, the Context API provides a mechanism to share data across components without complications. The provider is a React component that makes data available to its descendant components. When one of those descendants accesses the shared data, it becomes a consumer. 

To use the React Context API, we start by creating a React context object, a named object created by the `React.createContext()` function.

```jsx
const MyContext = React.createContext();
```

Context objects include a `.Provider` property that is a React component. It takes in a `value` prop to be stored in the context.

```jsx
<MyContext.Provider value="Hello world!">
   <ChildComponent />
</MyContext.Provider>
```
That value — in this case, the string `"Hello world!"` — is available to all its descendent components. Descendent components — in this case, `ChildComponent` — can then retrieve the context's value with React’s `useContext()` hook.

```jsx
import { useContext } from 'react';
import { MyContext } from './MyContext.js'

const ChildComponent = () => {
  const value = useContext(MyContext);
  return <p>{value}</p>;
}
// Renders <p>Hello, world!</p>
```

The `useContext()` hook accepts the context object as an argument and returns the current value of the context. Rejoice — prop drilling that value is no longer needed!

> Note: If a component attempts to use a context that isn’t provided by one of its ancestors, `useContext()` will return `null`. 

> Note: In some older React applications, you might instead see `SomeContext.Consumer` used to subscribe to a Context. That alternative is generally considered bad practice and avoided for being overly verbose and difficult to work with.

Creating and Consuming Context

You saw in the last three exercises how Contexts can share data in an area of a React application. Now we're going to show the common coding patterns many React developers use with Contexts and their `.Provider` components.

To start, it's common for React applications to create a "wrapper" component around a `.Provider` component. The wrapper component can provide a value of its choosing, often one of its props or a string literal, to the `.Provider` component. 

For example, here's a `ThemedMessage` component that returns the `ThemeContext.Provider` component wrapped around any `children` components it receives. `ThemedMessage` also assigns a value using a `theme` prop:

```js
const ThemeContext = React.createContext();

const ThemedMessage = ({ children, theme }) => {
  return (
    <ThemeContext.Provider value={theme}>
      This content is in {theme} mode!
      {children}
    </ThemeContext.Provider>
  );
};
```

Wrapper components like `ThemedMessage` can then be used in place of a `.Provider` component to wrap children:

```js
// Renders:
// This content is in dark mode! Hooray!
const MyComponent = () => {
  return (
    <ThemedMessage theme="dark">
      Hooray!
    </ThemedMessage>
  )
};
```

In this exercise, you'll prepare the application for more changes later on by setting up a dedicated wrapper component for the `ThemeContext` Context. We'll refactor `ThemeContext` so that later it can provide more than just the `theme` string to its consumers.

Provider Wrappers

You've seen how React Context Providers can be used in multiple places in a React app. Here's an brief example of a `GreeterContext` used to set up different greetings for child components:

```js
<GreeterContext.Provider value="Salut!">
  <ChildComponent />
</GreeterContext.Provider>
<GreeterContext.Provider value="Hallo!">
  <ChildComponent />
</GreeterContext.Provider>
```

A Context Provider may be a child in the application tree underneath an earlier Context Provider. Components subscribing to a Context's Provider will receive the value for the `.Provider` component closest to them in the application tree. This pattern is sometimes referred to as **nesting**.

```js
<GreeterContext.Provider value="Salut!">
  <HighLevelComponent> {// GreeterContext's value is "Salut!" here}

    <GreeterContext.Provider value="Hallo!">  
      <LowLevelComponent /> {// GreeterContext's value is "Hallo!" here}
    </GreeterContext.Provider>

  </RootComponent>
</GreeterContext.Provider>
```

In this example, we have two components that are used within the `GreeterContext.Provider`: `HighLevelComponent` and `LowLevelComponent`. Each component will use the value of the nearest `GreeterContext.Provider`. In this case, `HighLevelComponent` will have the value `"Salut!"` when using `GreeterContext` while the `LowLevelComponent` will have the value `"Hallo!"`.

We're going to use Context nesting to set up nested theming in our contacts management app:
* One root context around the entire application will set up a root theme for the entire application.
* A nested context in each section of contacts will override the root theme for their section's contact items.


Nested Providers

Suppose you're tasked with sending a message from the 15th floor of a building to the 1st floor. Instead of sending it directly, you have to pass it through a person on every single floor. Seems inefficient, right? This is similar to what happens in some React applications.

You might be building a React application where data is stored in a high-level `GrandParent` component. Then, you need to pass that data through a `Parent` component and eventually to a `Child` component to display it. 

This is a common and quite powerful pattern in React applications called "prop drilling".  In **prop drilling**, a piece of data is cascaded through multiple components in the hierarchy, just like our building analogy. The prop is "drilled" from a high-level component down through middle-level components down to a low-level component.

When props only have to be drilled through 1-2 components, prop drilling can be manageable and preferable for small applications. However, with more layers, it introduces challenges such as: 
* It bloats your code and makes it harder to understand or reuse the middle components.
* It causes middle components to re-render for changes to drilled props even if they don’t use those props themselves.

In this lesson, we'll take a look at React's **Context API**, a common approach to get around unnecessary prop drilling. Context is a feature of React that allows us to create a piece of centralized state that any component within an area of your application can subscribe to.

By the end of the lesson, you'll learn:
* How a React context provides shared state to React components
* Creating a context to provide a value to descendant React components
* Consuming that value in descendant React components
* Updating the context value in descendant React components
* Structuring nested providers for the same type of context

Let's get started!

Introduction

The previous exercise had you set up a wrapper component around a Context `.Provider` component. Now we're going to make use of that wrapper component by working with React state.

Many React applications use prop drilling to pass down two values: a piece of state and the state updater function to update that state. Child components may then use the state updater function to change the state of their ancestors. For example:

```js
const CounterApp = () => {
  const [count, setCount] = useState(0);

  return (
    <Counter count={count} setCount={setCount} />
  );
};
```

In this example, `Counter` can use the `setCount()` function to update the `count` value of `CounterApp`.

React Contexts can also be used to provide state and state updater functions. One common pattern is to have the context provide an object containing both of those values. Child components that consume the context can then use both (or either of) the state and the state updater function.

In this example, `CounterArea` provides the `count` value and the `setCount()` function to its descendants using context. The `Counter` component extracts both values from the provided context.

```js
const CounterContext = React.createContext();

const CounterArea = ({ children }) => {
  const [count, setCount] = useState(0);

  return (
    <CounterContext.Provider value={{ count, setCount }}>
      {children}
    </CounterContext.Provider>
  );
};

const Counter = () => {
  const { count, setCount } = useContext(CounterContext);

  return (
    <button onClick={() => setCount(count => count+1)}>
      {count}
    </button>
  );
};

const CounterApp = () => {
  return (
    <CounterArea>
      <Counter />
    </CounterArea>
  )
} 
```

In this exercise, you'll add logic to the `ThemeArea` component that sets up a piece of state and a state updater function for its context. In doing so, you'll allow the `ThemeContext` to have its theme updated by child components. 


Updating Context

Congrats, you've finished the React Context lesson! Let's recap what you learned:

* **Prop drilling** is the term for the common React pattern of data being passed as a prop through a large number of components in an application.
* **Contexts** allow us to avoid prop drilling pieces of application state shared by many components. Contexts come with a `.Provider` component that can also take in a value to be made available to child components – without having to prop drill the value.
* Child components, acting as **Consumers**, may subscribe to a Context’s value from their closest parent **Provider** with React’s `useContext()` hook. Components subscribing to a Context will receive the value for the Provider closest to them in the application tree.
* Providers may be given an object containing the React state and its corresponding state updater function. Subscribing child components may then use the state updater function to update the state for the Context.

Context is one of the many ways React apps can share state across many components without manual prop drilling. Keep in mind, though, that it's best used sparingly and only for prop-drilled values that don't change very frequently. You'll see later in the Performance lesson of this course how overusing Context can cause performance issues.

Keep in mind, too, that Context is not always the best solution for your application's architecture. There are other ways to handle states, such as Redux, `useReducer`, or just `useState` and prop drilling (which isn't always a problem).