Preventing The React Context From Turning Into Pyramids with Typesafe Composer

As developers, we experience such scenarios in our daily coding sessions, where extremely abstract and scattered React context logics can quickly become unmanageable when used under one provider.

I was the one who dealt with a core provider logic involving five or more nested contexts mixed together. The project was pretty old and odd 🙃 but I still had to take action on the contexts. Hence, I checked the inner functionality of each, which resulted in me wasting hours as the inner logic concluded that the functions on the other side needed to be analyzed.

In my case, the intention to check wasn't arbitrary though, there was race-condition between the providers and I was pretty sure that it was about the ordering.

At first, I thought to myself, "Of course it's not going to take long to figure this out", but it turned out to be "Claude, reorder the providers"..

Sometimes, the providers are not designed only to be responsible with passing the props using React states. We also utilize them to derive or calculate with utility functions before passing to the context's state during the hydration or later, depending on the circumstances.

In my scenario, the provider was likely a candidate to be Great Pyramid of Giza due to its large amount descending structure. Have a look:

1export default function StreamProvider({
2  children,
3  payload,
4}: StreamProviderProps) {
5  const worker = useWorker();
6  const stream = useStream(worker, payload);
7
8  return (
9    <StreamStatusContext.Provider value={stream.status}>
10      <StreamMetaContext.Provider value={stream.meta}>
11        <StreamPayloadContext.Provider value={stream.payload}>
12          <StreamErrorContext.Provider value={stream.error}>
13            <StreamPayloadsContext.Provider value={stream.payloads}>
14              {children}
15            </StreamPayloadsContext.Provider>
16          </StreamErrorContext.Provider>
17        </StreamPayloadContext.Provider>
18      </StreamMetaContext.Provider>
19    </StreamStatusContext.Provider>
20  );
21}

It's a client-side wrapper, acting as a communication channel between the worker and the main thread for UX feedback to keep the user busy with some UI stuffs during the internal worker processes.

The last maintenance was carried out about a year ago, just before React 19 was introduced. So, the newer syntax, the better readability.

The .Provider part of the syntax is now obsolete and redundant. If we trim it out then the code would look like this:

1export default function StreamProvider({
2  children,
3  payload,
4}: StreamProviderProps) {
5  const worker = useWorker();
6  const stream = useStream(worker, payload);
7
8  return (
9    <StreamStatusContext value={stream.status}>
10      <StreamMetaContext value={stream.meta}>
11        <StreamPayloadContext value={stream.payload}>
12          <StreamErrorContext value={stream.error}>
13            <StreamPayloadsContext value={stream.payloads}>
14              {children}
15            </StreamPayloadsContext>
16          </StreamErrorContext>
17        </StreamPayloadContext>
18      </StreamMetaContext>
19    </StreamStatusContext>
20  );
21} 

I believe this one may likely sound something new. When the providers are being used on the client side with bunch of nested contexts just like the one above, we usually do require comments but since we know it's internals, we're just skipping that part because, why not ✨

However, if you're the one working with a team, you might need to let the other developers know the purpose of the contexts unless the naming convention is clear enough or the context is pretty straightforward. Then I assure you, the linters will be problematic.

No matter using biome or eslint with prettier. When you add a comment and save the file, your existing formatter may relocate the comment you made, which could cause an error, syntactically.

There is a workaround to prevent this linter/formatter behavior when the file saved, it's ugly but at least something better:

And here is the solution that we're about to see to all these junky formatting behaviors:

Starting with creating a new file called composeProviders.tsx with .tsx extension and place it inside your lib folder or wherever you think is suitable.

The .tsx extension is mandatory and not arbitrary as we're working with the React components. Don't forget to take the difference into account.

First, we're gonna need to create a type to let the composer know that we're working explicitly with React components. So our providers's type can be inferred by the composer.

1// @/lib/composeProviders.tsx
2import type { ComponentType, ReactNode } from "react";
3
4// we do not need to export since it only belongs to the composer.
5type StoredProvider = ComponentType<{ value: never; children: ReactNode }>;
6type RenderableProvider = ComponentType<{
7  value: unknown;
8  children: ReactNode;
9}>;

The reason we used unknown for the type of context value is that the composer can accept any kind of value that might be controlled inside of the file where it's being passed whether via satisfies or as. I know it's less type-safe but you can use generic types to achieve 1o1 type inferring by simply converting the Provider type to a generic type.

never is used in the tuple on purpose: ComponentType<{ value: never }> accepts any provider (parameter contravariance). But then we need a second, wider type for rendering.

I wrote a comprehensive deep dive in my earlier articles. If you feel you lack knowledge about writing generic types, I definitely recommend checking it out 🚀

Our context type ready. Now let's design our entry point for the composer because we're gonna need to work with mapped arrays to be able to generate the composition for the React contexts.

1// again no 'export'
2type ProviderEntry = readonly [StoredProvider, unknown, string];

Now the StoredProvider indicates that we're solely allowing 3 arguments in a tuple array. readonly determines that we have nothing to do other than passing the undergoing array items to the subsequent action or wherever it goes.

Consider that the readonly type modifier is only permitted on array and tuple literal types. So we can't use it for the ContextProvider

We're gonna need something that properly handles the order of the contexts properly as well as slightly different approach than the traditional array mapping mechanism. Unlike the traditional method, it should not use intermediate JavaScript methods with multiple maps and sorts in terms of performance and readability.

Meet with reduceRight(). It's viable particularly for this implementation due to it's mapping all the elements in an array, in descending order.

So everything turns out to this when wrapped altogether:

1import type { ComponentType, ReactNode } from "react";
2
3type StoredProvider = ComponentType<{ value: never; children: ReactNode }>;
4type RenderableProvider = ComponentType<{
5  value: unknown;
6  children: ReactNode;
7}>;
8type ProviderEntry = readonly [StoredProvider, unknown, string];
9
10export function composeProviders(
11  providers: ProviderEntry[],
12  children: ReactNode,
13): ReactNode {
14  return providers.reduceRight((acc, [Provider, value, key]) => {
15    const P = Provider as RenderableProvider;
16    return (
17      <P key={key} value={value}>
18        {acc}
19      </P>
20    );
21  }, children);
22}

Breaking down in order:

• Takes multiple [Provider, value, key] entries.
• Wraps children with every provider automatically.
• Uses reduceRight() to preserve provider nesting order.
• The first provider in the array becomes the outermost provider.

Everything we've done so far was to be able to minimize the complication of pyramid effect and nothing is harder than it's implementation. We're gonna only need to compose and get rid of the pyramid like this:

1export default function StreamProvider({
2  children,
3  payload,
4}: StreamProviderProps) {
5  const worker = useWorker();
6  const stream = useStream(worker, payload);
7
8  return composeProviders(
9    [
10      [StreamStatusContext, stream.status, "status"], // comment never shifts down
11      [StreamMetaContext, stream.meta, "meta"],
12      [StreamPayloadContext, stream.payload, "payload"],
13      [StreamErrorContext, stream.error, "error"],
14      [StreamPayloadsContext, stream.payloads, "payloads"],
15    ],
16    children,
17  );
18}

Remember that I mentioned earlier that we can map our types out strictly? So basically with the previous implementation, a mismatched pair compiles and fails at runtime.

As an alternative here is a generic factory removes the cast and type checks each provider/value pair at the call site:

1import type { ComponentType, ReactNode } from "react";
2
3type ProviderEntry = {
4  readonly key: string;
5  readonly render: (children: ReactNode) => ReactNode;
6};
7
8export function providerEntry<T>(
9  Provider: ComponentType<{ value: T; children: ReactNode }>,
10  value: T,
11  key: string,
12): ProviderEntry {
13  return {
14    key,
15    render: (children) => (
16      <Provider key={key} value={value}>
17        {children}
18      </Provider>
19    ),
20  };
21}
22
23export function composeProviders(
24  providers: readonly ProviderEntry[],
25  children: ReactNode,
26): ReactNode {
27  return providers.reduceRight((acc, { render }) => render(acc), children);
28}

Implementation fairly longer but better:

1export default function StreamProvider({
2  children,
3  payload,
4}: StreamProviderProps) {
5  const worker = useWorker();
6  const stream = useStream(worker, payload);
7
8  return composeProviders(
9    [
10      providerEntry(StreamStatusContext, stream.status, "status"),
11      providerEntry(StreamMetaContext, stream.meta, "meta"),
12      providerEntry(StreamPayloadContext, stream.payload, "payload"),
13      providerEntry(StreamErrorContext, stream.error, "error"),
14      providerEntry(StreamPayloadsContext, stream.payloads, "payloads"),
15    ],
16    children,
17  );
18}

Now, in order to test it out, as instance let's deliberately mistaken the passed state using the stream.status for StreamMetaContext like this:

1providerEntry(StreamMetaContext, stream.status, "meta"),

yields a type error at compile time:

1Argument of type 'StreamStatus | null | undefined' is not assignable to parameter of type 'unique symbol | StreamMeta | null | undefined'.
2  Type '"COMPLETED"' is not assignable to type 'unique symbol | StreamMeta | null | undefined'.

The error in the IDE looks like this:

Ultimately, it's much safer and solid path to go with in prod-grade apps without concerning about runtime/compile issues.

The takeaways already given above so It appears to me that there is no more saying to be added below here😀. Of course you can utilize state managers like Redux or Zustand for smaller implementations depending on the use case and not tangle with any of this but if you think it's an overhead and willing to stay native to React, here is the solution for all that spaghetti or pyramid context chains.

Thanks for reading.

It's again a late night, 02:27 AM.