React Context - In the Real World

Re-thinking React

Context provides a new way to think about how data flows through a React application. This means we a have a chance to explore new ways of designing our React applications.

As we'll discover in this tutorial, Context provides new ways to help scale large applications. It can help standardize shared application state, and the ways it can be mutated. It can help reduce boilerplate code and make changes to application structure less painful.

To help illustrate the ways Context can be used in a real application, we'll use an example. However, since Context is really only helpful in substantial applications, we're going to need to build up this example a bit before we can see how Context can help us.

With that in mind, let's get started!

The Breakfast Club

Having grown tired of your success as a frontend web developer, in the summer of 1984 you decide to start a new brick and mortar venture the town of Shermer, Illinois. You open a breakfast restaurant specializing in waffles and coffee. You decide to build a React application to help your staff streamline the ordering process.

There are three different sections of our example application, allowing staff to manage breakfast orders from customers. One section to place new orders, one to view orders that need to be cooked, and one to view orders that need to be served.

To begin building our application, let's start with its most basic structure - the data making up the application state.

What is the data that will drive the functionality of our app?

If you strip away all of the UI and UX, what is the actual information being presented to the user?

All of the data being displayed or manipulated in our application revolves around the orders being placed by customers. So the state of our application can at any point be represented by just a list of orders currently in our system.

// application state (a list of all orders placed)
const orders = [
  {
    name: "Molly R.",
    waffles: 1,
    coffee: 1,
    status: "waitingToBeCooked",
    dateCreated: 476625600 /* a unix timestamp, the result of Date.now() */
  },
  { name: "Emilio E.", waffles: 0, coffee: 1, status: "done", dateCreated: 476653626 },
  { name: "Paul G.", waffles: 2, coffee: 1, status: "waitingToBeServed", dateCreated: 476659347 },
]

This is the single source of truth for our application. It is the data that will drive all of the components in the component tree, and it is the data that will be manipulated when users interact with the application.

Now that we know what our state will look like, let’s start breaking the UI down into a component tree.

There is no single correct way to structure a react component tree. We could start with one giant component making up the entire application. We could break the individual tabs down into smaller and smaller components until we end up with a component tree with many levels. As your application scales, the flexibility of React allows you to determine where it is appropriate to draw the lines - how to break up an entire application into manageable, reusable pieces.

In our case, it seems to make sense that each section of our application could be its own component. Each tab has its own functionality, independent from the others. They do, however, all rely on the same data. They all rely on our application state - the list of orders. This means we must to find a place for this state to live that is accessible for all three of them.

In our design, we’ve used the concept of “hoisting state”. Since all three of our tab components need access to the application state, we need to move that state up the component tree, (ie hoist it) to a parent component encompassing all three tab components as children. We can then pass down data from that parent component to the child components that need it. And when user interactions need to mutate that data, we can pass down functions which, when called, will that mutate that state. This data, and functions which mutate that data, can be passed down to the child components in the form of props.

function BreakfastClubApp() {
  const [orders, setOrders] = useState([]);

  function addNewOrder(name, waffles, coffee) {
    /* add new order via setOrders() */
  }

  function changeOrderStatus(orderDate, newStatus) {
    /* find relevant order and change status via setOrders() */
  }

  return (
    <div>
      Open Orders: {orders.filter(/* check status */).length}
      <OrderTab addNewOrder={addNewOrder} />
      <CookTab orders={orders} markOrderReady={changeOrderStatus} />
      <OrderUpTab orders={orders} markOrderDone={changeOrderStatus} />
    </div>
  );
}

This should feel pretty familiar so far. We have a basic react application set up, using state which drives several different nested components in our component tree.

Now let’s think back to Context. If Context is an alternative way to share data between components (instead of via props), could that be helpful here?

In our application, the state object (ie the data we need to share between components) is never more than one step away from where it's needed. Context could provide a different API for how this data is shared, but it doesn’t seem like it would benefit our application in any meaningful way. The structure of our application would still remain the same.

So let’s ramp up the complexity a bit. Since Context is meant to improve how data is shared in large applications, let's build on our example to see if we can find a situation where Context would actually help us.

Scaling up

Things are going well at the Breakfast Club. Waffle sales are increasing by the day, and thanks to your React application the order processing is efficient and scalable. With all this increased revenue, you decide to expand your application. In addition to handling order processing, you want to get a better idea of how sales have progressed over time. You add a new section of your application to provide some visualizations of the same order data.

What's changed?

Our new "Sales" section looks through the list of orders placed in our application, and displays some information to the user about those orders.

We’re not accessing any new data. The state of our application can still be represented by just a list of orders. All we’re doing is adding new visualizations of the same state. We have new sections of our application, which also rely on this order data. We’re building up our component tree with more and more components that all rely on the same data.

Our application now has two distinct sections - one for visualizing order history and sales data, and the other for actually placing and processing new orders. It seems to make sense that these two distinct sections could be their own components, both with their own child components with their own responsibilities. Since the child components of both the Sales Tab and Order Tab components rely on our order state, we again need to hoist that state up to a parent component encompassing every component that needs access to it.

We’ve basically followed the exact same patterns from our original application. The only difference is that our component tree is larger. Before, our order state was never more than one step away from a component that needed access to it. Now, the components that need access to our order state are two steps away in our component tree. This means that even if a component doesn’t need access to the order state (like the Order Tab and Sales Tab components), it still must take in that data via its props, if there is a child component beneath it that needs access.

In code, we still just pass down the data to the child components that need it. Both order state and functions to manipulate order state get dispersed throughout the component tree via props. The only difference is that there are more levels of our component tree to traverse.

function BreakfastClubApp() {
  const [orders, setOrders] = useState([]);

  function addNewOrder(name, waffles, coffee) {
    /* add new order via setOrders() */
  }

  function changeOrderStatus(orderDate, newStatus) {
    /* find relevant order and change status via setOrders() */
  }

  return (
    <div>
      <SalesTab orders={orders} />
      <OrderTab
        orders={orders}
        addNewOrder={addNewOrder}
        changeOrderStatus={changeOrderStatus}
      />
    </div>
  );
}

So now our application is a little more complex. Let’s think back to Context, and ask ourselves the same question as last time. If Context is an alternative way to share data between components (instead of via props), could that be helpful here?

Now our application has data that is shared between more components, and it’s a little more difficult to get that data down to those components. We have to pass our order state down from the parent component where it lives, through components that don’t need access to that state, down to the child components that do. This is called “prop drilling”, and it's a pattern that happens often in large React component trees.

In order to get our application state to the components that need it, we're passing a lot of data around our component tree via props. Context allows us to share data between components without handing it off via props at every level. Let's see how the structure of our application would change if we used Context to share our application state with the components that need it, instead of props.

Context is key

As we learned in the previous tutorial, data shared via Context lives outside the component tree. When a parent component shares data via Context, it becomes accessible to any child component existing beneath it in the component tree.

If we use Context to share our application state, let's see how that changes our application diagram.

Notice how the Sales Tab and Order Tab components no longer need awareness of the order data. Since we're not using props to pass that data directly down to their respective child components (which do need access to the order data), they themselves don't need access to the order data. Instead, every individual component can pull just the data it needs directly from the Context object.

Notice also that in addition to the order data, our Context object is also providing methods to mutate that order data ("add new order" and "change status"). This might seem a little strange, as we've previously talked about Context as a way to share data between components. However, in Javascript, functions are first-class citizens. They are objects. They are data. Which means they can be stored in variables, or properties on other objects, and passed around just like scalar values. This means that in addition to scalar values, our Context object can also share functions. This is great news for us, because it means that in addition to sharing the state of our application (order data) via Context, we can just as easily share methods to mutate the state of our application.

So what would this Context object that we've outlined above actually look like in code?

const ApplicationContext = React.createContext({
  orders: [],
  addNewOrder: (name, waffles, coffee) => {},
  changeOrderStatus: (orderDate, newStatus) => {}
});