An Introduction To Context Propagation In JavaScript — Smashing Journal

React popularized the concept of context-propagation inside our purposes with its context API. On the planet of React, context is used as a substitute for prop-drilling and synchronizing state throughout totally different components of the apps.

“Context offers a solution to go knowledge by means of the part tree with out having to go props down manually at each degree.”

— React Docs

You may think about React’s context as some sort of a “wormhole” which you can go values by means of someplace up your part tree and entry them additional down in your kids’s parts.

The next snippet is a slightly simplistic (and fairly ineffective) instance of React’s context API, but it surely demonstrates how we will use values outlined increased up within the part tree with out passing them explicitly to the kid parts.

Within the snippet beneath, we now have our app that has a Shade part in it. That Shade part shows a message containing the message outlined in its guardian part — the app, solely with out having it being handed immediately as a prop to the part, however slightly — having it “magically” seem by means of using useContext.

import {createContext, useContext} from 'react'

const MyContext = createContext();

operate App() {
  return (
    <MyContext.Supplier worth={colour: "crimson"} >
      <Shade/ >
    </MyContext.Supplier >
  );
}

operate Shade() {
  const {colour} = useContext(MyContext);

  return <span >Your colour is: {colour}</span >
}

Whereas the use-case for context propagation is evident when constructing user-facing purposes with a UI framework, the necessity for the same API exists even when not utilizing a UI framework in any respect and even when not constructing UI.

Why Ought to We Care About This?

In my eyes, there are two causes to really attempt to implement it.

First, as a person of a framework — it is extremely necessary to know the way it does issues. We regularly take a look at the instruments we use as “magic” and issues that simply work. Making an attempt to construct components of them for your self demystifies it and helps you see that there’s no magic concerned and that below the hood, issues will be fairly easy.

Second, the context API can turn out to be useful when engaged on non-UI apps as nicely.

Each time we construct any form of a medium to a big software, we’re confronted with capabilities that decision each other, and the decision stack might go a number of layers deep. Having to go arguments additional down can create loads of mess — particularly if you happen to don’t use all these variables in any respect ranges. On the planet of React, we name it “prop drilling.”

Alternatively, if you’re a library writer and also you depend on callbacks handed to you by the buyer, you might have variables declared at totally different ranges of your runtime, and also you need them to be out there additional down. For instance, take a unit testing framework.

describe('add', () => {
  it('Ought to add two numbers', () => {
    count on(add(1, 1)).toBe(2);
  });
});

Within the following instance, we now have this construction:

1. describe will get referred to as, and calls the callback operate handed to it.
2. throughout the callback, we now have an it name.

What Do We Need Achieved?

Let’s now write the fundamental implementation for our unit testing framework. I’m taking the very naive and happy-path strategy to make the code so simple as attainable, however this, in fact, not one thing you need to use in actual life.

operate describe(description, callback) {
  callback()
}

operate it(textual content, callback) {
  strive {
    callback()
    console.log("✅ " + textual content)
} catch {
    console.log("🚨 " + textual content)
  }
}

Within the instance above, we now have the “describe” operate that calls its callback. That callback might include totally different calls to “it.” “it,” in its flip, logs whether or not the check is profitable or failing.

Let’s assume that, together with the check message, we additionally need to log the message from “describe”:

describe('calculator: Add', () => {
  it("Ought to appropriately add two numbers", () => {
    count on(add(1, 1)).toBe(2);
  });
});

Would log to the console the check message prepended with the outline:

"calculator: Add > ✅ Ought to appropriately add two numbers"

To do that, we have to in some way have the outline message “jump over” the person code and, in some way, discover its method into the “it” operate implementation.

What Options Would possibly We Attempt?

When attempting to unravel this drawback, there are a number of approaches we’d strive. I’ll attempt to go over a number of, and reveal why they may not be appropriate in our situation.

• Utilizing “this”
  We may attempt to instantiate a category and have the info propagate by means of “this,” however there are two issues right here. “this” could be very finicky. It doesn’t at all times work as anticipated, particularly when factoring arrow capabilities, which use lexical scoping to find out the present “this” worth, which implies our shoppers should use the operate key phrase.
  Together with that, there isn’t a relationship between “check” and “describe,” so there isn’t a actual solution to share the present occasion.
• Emitting an occasion
  To emit an occasion, we’d like somebody to catch it. However what if we now have a number of suites operating on the similar time? Since we now have no relationship between the check calls and their revered “describes,” what would forestall the opposite suites from catching their occasions as nicely?
• Storing the message on a worldwide object
  International objects undergo from the identical issues as emitting an occasion, and likewise, we pollute the worldwide scope.
  Having a worldwide object additionally implies that our context worth will be inspected and even modified from outdoors of our operate run, which will be very dangerous.
• Throwing an error
  This could technically work: our “describe” can catch errors thrown by “it,” but it surely implies that on the primary failure, we’ll halt the execution, and no additional exams will be capable of run.

Context To The Rescue!

By now, you could have guessed that I’m advocating for an answer that will be considerably comparable in design to React’s personal context API, and I feel that our fundamental unit testing instance may very well be candidate for testing it.

The Anatomy Of Context

Let’s break down what are the components that React’s context is comprised of:

1. React.createContext — creates a brand new context, principally defines a brand new specialised container for us.
2. Supplier — the return worth createContext. That is an object with the “supplier” property. The supplier property is a part in itself, and when used inside a React software, it’s the entry to our “wormhole.”
3. React.useContext — a operate that, when referred to as inside a React tree that’s wrapped with a context, serves as an exit level from our wormhole, and permits to tug values out of it.

Let’s check out React’s personal context:

It appears to be like just like the React context object is kind of complicated. It comprises a Supplier and a Shopper which can be truly React Components. Let’s maintain this construction in thoughts going ahead.

Understanding what we now learn about React’s context, let’s attempt to suppose how its totally different components ought to work together with our unit testing instance. I’m going to make a nonsensical situation simply so we will think about the totally different parts working in actual life.

const TestContext = createContext()

operate describe(description, callback) {
  // <TestContext.Supplier worth={{description}} >
callback()
  // </TestContext.Supplier >
}

operate it(textual content, callback) {
  // const { description } = useContext(TestContext);

  strive {
    callback()
    console.log(description + " > ✅ " + textual content)
  } catch {
    console.log(description+ " > 🚨 " + textual content)
  }
}

However clearly, this can not work. First, we will’t use React Components in our vanilla JS code. Second, we can not use React’s context outdoors of React. Proper? Proper.

So let’s adapt that construction into actual JS:

const TestContext = createContext()

operate describe(description, callback) {

  TestContext.Supplier({description}, () => {
callback()
  });
}

operate it(textual content, callback) {
  const { description } = useContext(TestContext);

  strive {
    callback()
    console.log(description + " > ✅ " + textual content)
  } catch {
    console.log(description+ " > 🚨 " + textual content)
  }
}

OK, so that is beginning to look extra like JavaScript. What do we now have right here?

Effectively, largely — as an alternative of our ContextProvider part, we’re utilizing TextContext.Supplier, which takes an object with the references to our values, and useContext() that serves as our portal — so we will faucet into our wormhole.

Can this work, although?
Let’s strive.

Drafting Our API

Now that we now have the final idea of how we’re going to make use of our context, let’s begin by defining the capabilities we’re going to show. Since we already know the way the React Context API appears to be like like, we will base it on that.

operate createContext() {
  return {
    Supplier,
    Shopper
  }

  operate Supplier(worth, callback) {}

  operate Shopper() {}
}

operate useContext(ctxRef) {}

We’re defining two capabilities, identical to React. createContext and useContext. createContext returns a Supplier and a Shopper, identical to React’s context, and useContext takes in a context reference.

Some Ideas To Be Conscious Of Earlier than We Dive In

What we’re going to do from right here on will construct upon two core concepts which can be necessary for JavaScript builders. I’m not going to clarify them right here, however if you happen to really feel shaky about these subjects, you’re greater than inspired to learn up on them:

1. JavaScript Closures
   From MDN: “A closure is the mix of a operate bundled collectively (enclosed) with references to its surrounding state (the lexical atmosphere). In different phrases, a closure offers you entry to an outer operate’s scope from an interior operate. In JavaScript, closures are created each time a operate is created, at operate creation time.”
2. JavaScript’s Synchronous Nature
   At its base, Javascript is synchronous and blocking. Sure, it has async guarantees, callback’s and async/await — and they’ll require some particular dealing with, however for probably the most half, let’s deal with JavaScript as synchronous, as a result of until we get to these realms, or VERY bizarre legacy edge case browser implementations, JavaScript code is synchronous.

These two seemingly unrelated concepts are what enable our context to work. The idea is that, if we set some worth inside Supplier and name our callback, our values will stay and be out there all all through our synchronous operate run. We simply want a solution to entry it. That’s what useContext is for.

Storing Values In Our Context

Context is used to propagate knowledge all through our name stack, so the very first thing we need to do is definitely retailer info on it.
Let’s outline a contextValue variable inside our createContext operate. Residing throughout the closure of createContext, ensures that each one capabilities outlined inside createContext may have entry to it even in a while.

operate createContext() {
  let contextValue = undefined;

  operate Supplier(worth, callback) {}

  operate Shopper() {}

  return {
    Supplier,
    Shopper
  }
}

Now, that we now have the worth saved within the context, our Supplier operate can retailer the worth it accepts on it, and the Shopper operate can return it.

operate createContext() {
  let contextValue = undefined;

  operate Supplier(worth, callback) {
    contextValue = worth;
  }

  operate Shopper() {
    return contextValue;
  }

  return {
    Supplier,
    Shopper
  }
}

To entry the info from inside our operate, we will merely name our Shopper operate, however simply so our interface works precisely like React’s, let’s additionally make useContext have entry to the info.

operate useContext(ctxRef) {
  return ctxRef.Shopper();
}

Calling Our Callbacks

Now the enjoyable half begins. As talked about, this technique depends on JavaScript synchronous nature. Which means from the purpose we run our callback, we know, for sure, that no different code will run — which implies that we don’t actually want to guard our context from being modified throughout our run, however as an alternative, we solely want to scrub it up instantly after our callback is finished operating.

operate createContext() {
  let contextValue = undefined;

  operate Supplier(worth, callback) {
    contextValue = worth;
    callback();
    contextValue = undefined;
  }

  operate Shopper() {
    return contextValue;
  }

  return {
    Supplier,
    Shopper
  }
}

That’s all there may be to it. Actually. If our operate known as with the Supplier operate, all all through its execution it’ll have entry to the Supplier worth.

What If We Have A Nested Context?

Nesting of contexts is one thing that may occur. For instance, when I’ve a describe inside a describe. In such a case, our context will break when exiting the inner-most context, as a result of after every callback run, we reset the context worth to undefined, and since each layers of the context share the identical closure — the inner-most Supplier will reset the worth for the layers above it.

operate Supplier(worth, callback) {
  contextValue = worth;
  callback();
  contextValue = undefined;
}

Fortunately, it is extremely simple to deal with. When getting into a context, all we have to do is save its present worth in a variable and set it again to it after we exit the context:

operate Supplier(worth, callback) {
  let currentValue = contextValue;
  contextValue = worth;
  callback();
  contextValue = currentValue;
}

Now, at any time when we step out of context, it’ll return to the earlier worth, and if there are not any extra layers of context above, we’ll return to the preliminary worth — which is undefined.

One other function that we didn’t implement at the moment is the default worth for the context. In React, you may initialize the context with a default worth that might be returned by the Shopper/useContext in case we’re not inside a operating context.

Should you’ve acquired this far, you may have all of the data and instruments to attempt to implement it by your self — I’d like to see what you give you.

Is This Being Used Anyplace?

Sure! I truly constructed the context package deal on NPM that does precisely that, with some modifications and a bunch of extra options — together with full typescript assist, merging of nested contexts, return values from the “Supplier” operate, context preliminary values, and even context registration middleware.

You may examine the complete supply code of the package deal right here: https://github.com/ealush/vest/blob/newest/packages/context/src/context.ts

And it’s getting used extensively inside Vest validation framework, a type validation framework that’s impressed by unit testing libraries similar to Mocha or Jest. Context serves as Vest’s predominant runtime, as will be seen right here.

I hope you’ve loved this temporary intro to context propagation in JavaScript, and that it confirmed you that there’s no magic in any respect behind a few of the most helpful React APIs.

Additional Studying on Smashing Journal

(nl, il)