Beyond Context: Architecting High-Performance Fine-Grained Reactivity in React

The React Context Performance Trap

I hit Context re-render storms on this portfolio when ThemeContext and ProfileContext wrapped the entire tree. On elangodev.com I split providers, moved high-churn UI state local, and kept Context for slow-changing profile data — the pattern I use across blog, dashboard, and elangodev.com routes today.

React Context is one of the most widely misunderstood features in the React ecosystem. Commonly treated as a state management tool, Context is actually a dependency injection mechanism. Its primary role is to pass down values to deep child components without explicit prop-drilling. When state changes inside a Context Provider, React triggers a re-render of the entire descendant tree from that Provider downward, unless extreme precautions are taken. This happens regardless of whether individual components in that tree actually consume the specific slice of state that changed.

For applications handling high-frequency state updates—such as real-time WebSocket feeds, collaborative drag-and-drop boards, complex multi-step forms, or gaming dashboards—relying solely on Context for global state leads to severe rendering bottlenecks, degrading the Interaction to Next Paint (INP) metric and causing visible interface lag.

The Push vs. Pull Architecture: Bypassing the VDOM

To scale application reactivity, we must move from a Pull-based model (where React continuously diffs the Virtual DOM to check what changed) to a Push-based model (where the state container directly notifies only the specific components that need to change). This relies on the classic Publish-Subscribe (Pub/Sub) pattern.

By storing state outside the React component tree (in a plain JavaScript closure) and establishing a subscription architecture, we can selectively update components. React 18 formalized this paradigm with the introduction of useSyncExternalStore. This hook guarantees tear-free, concurrent-safe access to external data sources by hooking directly into React\'s internal fiber scheduler.

Building a Custom Subscription-Based Store from Scratch

Let\'s demystify how libraries like Zustand and Redux function under the hood by building our own lightweight, type-safe reactive store with zero third-party dependencies.

First, we define our store container which maintains state, holds a registry of listeners, and exposes a mechanism to trigger updates selectively:

type Listener = () => void; 

export function createStore<T>(initialState: T) {
  let state = initialState;
  const listeners = new Set<Listener>();

  return {
    getState: () => state,
    setState: (nextState: Partial<T> | ((prev: T) => Partial<T>)) => {
      const partial = typeof nextState === "function" ? nextState(state) : nextState;
      state = { ...state, ...partial };
      listeners.forEach((listener) => listener());
    },
    subscribe: (listener: Listener) => {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
  };
}

With this plain vanilla JS store, we need a custom hook to connect it back to React. The useSyncExternalStore hook requires two arguments (and an optional third for SSR): the subscription function and a function returning the snapshot of the state. We will also integrate a selector function to enable fine-grained, component-level state slicing.

import { useSyncExternalStore } from "react";

export function useStore<State, Slice>(
  store: ReturnType<typeof createStore<State>>,
  selector: (state: State) => Slice
): Slice {
  return useSyncExternalStore(
    store.subscribe,
    () => selector(store.getState())
  );
}

Let\'s see this in action. Suppose we have a global store representing a dynamic canvas board:

interface BoardState {
  x: number;
  y: number;
  zoom: number;
  title: string;
}

const canvasStore = createStore<BoardState>({
  x: 0,
  y: 0,
  zoom: 1.0,
  title: "My Collaborative Canvas",
});

Now, we can consume only the zoom level in a ZoomIndicator component. This component will only re-render when the zoom value changes, remaining completely unaffected when x, y, or title are updated:

function ZoomIndicator() {
  const zoom = useStore(canvasStore, (state) => state.zoom);
  return <div>Zoom Scale: {zoom * 100}%</div>;
}

Harnessing RxJS for Complex, Time-Based Reactivity

While basic custom stores are perfect for synchronous, UI-driven states, modern web applications often deal with highly asynchronous, complex, and declarative events (e.g., chat streams, mouse-tracking drag operations, network polling). For these scenarios, **RxJS** and reactive programming streams provide unparalleled power.

We can write a generic React hook that bridges the gap between an asynchronous RxJS Observable stream and standard React component state:

import { useState, useEffect } from "react";
import { Observable } from "rxjs";

export function useObservable<T>(observable$: Observable<T>, initialValue: T): T {
  const [value, setValue] = useState<T>(initialValue);

  useEffect(() => {
    const subscription = observable$.subscribe({
      next: (val) => setValue(val),
      error: (err) => console.error("Stream error:", err),
    });
    return () => subscription.unsubscribe();
  }, [observable$]);

  return value;
}

Using this pattern, we can easily orchestrate intricate debouncing logic. For instance, creating an auto-saving input stream that only sends requests to the server after 500ms of user typing inactivity, while showing a "saving" status dynamically to the UI, is straightforward with RxJS operators:

import { Subject } from "rxjs";
import { debounceTime, switchMap, map } from "rxjs/operators";

// A stream representing user input events
const inputSubject$ = new Subject<string>();

// Derived stream capturing saving states and operations
const savingStatus$ = inputSubject$.pipe(
  debounceTime(500),
  switchMap(async (text) => {
    // Simulated API Call
    await fetch("/api/save", { method: "POST", body: JSON.stringify({ text }) });
    return "Saved Successfully!";
  })
);

Architectural Matrix: Selecting Your Reactivity Model

Choosing the correct state architecture depends strictly on your use cases. The table below outlines how to map application patterns to specific architectures:

• React Context: Ideal for static configuration values, themes, user session setups, and localized dependency injection. Avoid for high-frequency updates.
• Custom Pub/Sub Stores (using useSyncExternalStore): Ideal for micro-frontend integrations, localized shared states, and high-frequency animations or real-time parameters without the overhead of external libraries.
• Zustand/Jotai: Recommended default for complex application states, dashboards, and enterprise-grade tools requiring built-in optimization tools and middleware.
• RxJS Observables: Best choice for highly asynchronous applications, telemetry, multi-channel WebSockets, and heavy, time-based event processing pipeline systems.

What I ship on elangodev.com today

Theme and profile stay in Context because they change rarely. Chat scroll position, dashboard filters, and animation clocks live in external stores or local component state. That split keeps blog reading smooth while the dashboard stays interactive — the same tradeoff I document in the site handbook when I explain React performance for portfolio apps.

If you are debugging Context storms, start by counting how often your provider value identity changes, then move only the high-frequency slices out. Full library migrations are optional; selective subscriptions usually fix the INP regressions first.

Where fine-grained reactivity helped on this codebase

The rich text experiments under /npm/react-lite-rich-text-editor needed character-level updates without re-rendering the full toolbar tree. Context-based selection state caused jank. Isolating caret and mark state into a narrower store (and memoized toolbar islands) restored typing smoothness.

On the marketing site I deliberately avoid exotic reactivity — RSC + props are enough. Fine-grained tools earn their complexity inside editors, canvases, and dashboards with high-frequency updates.

Profiling protocol before adopting a library

I record a performance profile while typing in the editor, look for Recalculate Style and React commit durations, then only then evaluate signals or subscription-based stores. Skipping profiling leads to cargo-cult rewrites that do not move INP.

Patterns that beat premature signals

• Split client components so static chrome does not subscribe to hot state.
• Colocate state with the editor surface.
• Use startTransition for non-urgent highlight recomputation.
• Keep public blog pages free of editor bundles via route-level code splitting.

The lesson I publish here: reactivity strategy is a product of measured UI cost, not of Twitter threads. elangodev.com’s public surface stays boring; the editor try pages carry the experimental stack and stay noindex.

Publishing vs experimenting

The blog explains the theory; /npm/*/try hosts the experiments and stays out of the AdSense crawl surface via robots and noindex layouts. That separation prevents “low value” judgments based on thin interactive shells while still letting me share real performance work.

If you only have one domain, use the same split: index the essay, noindex the playground. Reviewers reading the essay should not need the playground to understand the claims.

Closing guidance

Start with component split and transitions. Graduate to stores. Reach for fine-grained reactivity when profiles prove you need it. Publish the essay; noindex the lab. That is the elangodev.com playbook for performance writing that still clears a human content review.