A short review of when you should be using the React Context API

Giving a flower is a nice way to add romantic context to a situation. Photo by Evan Kirby on Unsplash

As you probably already know, React’s Context API just finally became official in version 16.3. Up until now It has been an experimental API and was generally considered an ‘advanced’ feature, as “Most applications will never need to use context”.

Now with the new API finally out and all the hype around it, I felt it encourages use that might be forced and not necessary.

I remembered the tweet about Context by Dan Abramov and I feel it should be used as the base for this discussion:

So what has changed since July 2016? Let’s examine all three if statements:

• The first clause states that if you are a library author and need to pass something down deeply, you should be fine with API changes and buggy updates. However, now with the new API being official — there is most likely no need to worry about buggy updates or frequent, breaking API changes.
• The second clause asks you to use a ‘Higher Order Component’ (HOC) instead of using the API directly. I feel this still stands strong — it fits well with patterns normally used with the Context API. It also mentions typical use-cases for context.
• The third and final clause urges you to file an issue if a library asks you to use context and ask them to provide a HOC, to further promote the idea of using HOCs to pass context.

So overall, we can conclude that since the Context API is now more reliable and safer to use, we can worry less about using it — but developers should still consider when to use it with care.

Let’s take a look at two typical use cases for the Context API:

#1: Dependency Injection

As I explained in my article about some very useful React tips, you can use React’s Context API to pass data to a deeply-nested component without polluting the interfaces all along the way.

Let’s see how it is done with the new Context API:

In this example, App renders the Post component inside the Provider , the HOC provided by the createContext function. This enables you to acquire the context, no matter how deeply nested the usage might be, by rendering the Consumer HOC, also provided by the same mechanism.

Post renders a Title and a Message , which consume the relevant values from the passed context object inside the Consumer .

This simple example demonstrates the simplicity and clarity of the new API, as it is very readable and easy to use.

#2: Theming

Building on the documentation example, let’s see how we can theme components using context:

Here we have two theme-able components — the ThemedButton and ThemedLabel . The button renders a label, which renders text.
By toggling between the themes on the state (using the extra button), the components cycle between two themes — bright text on a dark button, and dark text on a bright button. This is done with ease as the theme context provider is a ‘single source of truth’ for the theming options, and yet allows the theme to be easily consumed by all the theme-able components.

Final words

I’m glad the Context API became official. It’s a powerful tool that brings simplicity and elegance to otherwise cumbersome patterns to implement.
Just keep in mind to use it only when it is fitting.