Managing state in large React applications is difficult. Determining what state belongs locally to a component, what data a component receives from props, how much logic needs to be decoupled from a component, etc. directly affects an application's maintainability. One issue most developers face when developing a React application is 

. Sending data down an entire component tree just to reach a single component is unnecessary, especially if none of the intermediate components need this data. With 

, we can share global data (e.g., theme, time zone, i18n locale and user authentication status) with any component within the component tree without repeatedly passing data down as props. 

To understand why context is important, we must first understand the kinds of problems brought about by prop drilling.

Consider the following barebones React application that comes with i18n support and allows users to select a preferred language. For instance, within the footer, switching the language from "English" to "Español" translates the application's text from English to Spanish.

: For production-grade React applications, please use a dedicated i18n library like 

 component, you will notice that the props 

 are not used by this component whatsoever. Its sole purpose is to pass these props from the 

 component, then we would have to make modifications to:

And for larger applications, even more components would have to be refactored before you're able to successfully remove/add a single component.

With the same problem also arising with the 

 component has no use for besides just passing it straight down the component hierarchy, taking the context approach directly exposes these methods to lower-level components like the 

 component without introducing more bloat to intermediate components (in this case, the 

To demonstrate this, let's rewrite the application with context:

The first step to using context is to create a Context object with the 

const I18nContext = createContext({
  locale: LOCALES[0],
  translate: () => {},
  changeLocale: () => {}
});

This method accepts a single argument: the default data to share with consumer components if no matching provider component is found. Often, this data is replaced within the component responsible for rendering the provider component. Therefore, the main purpose of passing this data to the 

Every Context object provides the following:

, wrap the entire application so that any child component with an 

, can access the currently selected language (

// this.state = {
//   locale: LOCALES[0],
//   translate: this.translate,
//   changeLocale: this.changeLocale
// };

<I18nContext.Provider value={this.state}>
  <BrowserRouter>
    <Routes>
      <Route path="/" element={<Layout />}>
        <Route index element={<Home />} />
        <Route path="sign_in" element={<Login />} />
      </Route>
    </Routes>
  </BrowserRouter>
</I18nContext.Provider>

Here, the context's default value gets replaced by the 

 object, which has the same properties. The only difference is that the 

 component's state and actually do as they are named.  

 components no longer receiving any props, the 

 method becomes much cleaner and easier to reason about. Plus, we no longer have to track these props in the component hierarchy.

 component is now tightly coupled to the 

 component, then we could without making any additional modifications to other parts of the application.

 consumer component's render props, not from the 

function Footer() {
  return (
    <I18nContext.Consumer>
      {({ changeLocale, locale }) => (
        <footer className="footer">
          <select
            value={locale.code}
            onChange={(evt) => changeLocale(evt.target.value)}
          >
            {LOCALES.map((l) => (
              <option key={l.code} value={l.code}>
                {l.language}
              </option>
            ))}
          </select>
        </footer>
      )}
    </I18nContext.Consumer>
  );
}

 only made available in the component's rendering logic, this render props pattern prevents us from defining functions (that rely on these values, such as event handlers) outside of the rendering logic. So for the 

 changes, a different callback gets created upon each re-render. This isn't problematic for the example above, but for callbacks passed as a prop to lower-level components, it causes extra re-renders.

 Hook simplifies how components consume and update data from a context provider.

Let's see this in action by rewriting the application with function components calling the 

Creating the Context object and wrapping the entire application within the context's provider component remains the same as before. 

Instead of wrapping each component with a 

 Hook within the component's function body. This way, we eliminate the extra 

 wrapper components from the component hierarchy. Plus, we can access the context value anywhere within the component's function body, including functions defined within it and the 

 component, we can define the event handler, which calls the context's 

 method, outside of the rendering logic, like so:

 Hook accepts a single argument: a Context object (returned by the 

 method). It returns the current context value for that specific Context.

const { locale, translate, changeLocale } = useContext(I18nContext);

Anytime the provider's context value changes, any component subscribed to this context via 

: If you have multiple components subscribed to the same provider, and one of those components updates the provider's value, then every one of these components will re-render upon that update. Therefore, you may want to use the 

 Hook to avoid unnecessary, expensive re-renders.

Can React's Context API Replace State Management Libraries Like Redux?

Since React's Context API serves as a state management solution for a React application's global state, most developers believe that they can substitute a library like Redux for the Context API. However, the Context API is not a one-to-one replacement for Redux. 

Using Context, we define the global state within a component and supply that state to the context's provider component's 

 prop. But with Redux, we define the global state outside of the component hierarchy within a centralized store, which holds this state. 

Compared to Redux, Context requires a lot less setup (no actions, reducers, etc.), but can be difficult to debug in applications with lots of deeply nested components.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

useContext Hook - A Primer

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript