React Context Mastery: Automating State Architecture

JSON to React Context: Generating TypeScript Context from Data Shapes

React Context lets you share state across a component tree without prop drilling. When you have a JSON payload representing a shared piece of application state — user preferences, auth data, feature flags — generating the Context, Provider, and hook scaffolding from the JSON shape saves the repetitive typing work and ensures your types match your data from day one.

Live Example: User Preferences Context

// Input JSON
{
  "theme": "dark",
  "locale": "en-US",
  "font_size": 16,
  "notifications_enabled": true,
  "sidebar_collapsed": false
}

// Generated React Context
import React, { createContext, useContext, useState } from 'react';

interface RootContextType {
  theme: string;
  locale: string;
  font_size: number;
  notifications_enabled: boolean;
  sidebar_collapsed: boolean;
}

const RootContext = createContext<RootContextType | undefined>(undefined);

export function RootProvider({ children }: { children: React.ReactNode }) {
  const [state, setState] = useState<RootContextType>({
    theme: '',
    locale: '',
    font_size: 0,
    notifications_enabled: false,
    sidebar_collapsed: false,
  });

  return (
    <RootContext.Provider value={state}>
      {children}
    </RootContext.Provider>
  );
}

export function useRootContext() {
  const ctx = useContext(RootContext);
  if (!ctx) throw new Error('useRootContext must be used within RootProvider');
  return ctx;
}

Adding State Updates: Dispatch Pattern

The generated code provides the read shape. For a real preferences context, add a dispatch function or setter so consumers can update state:

import React, { createContext, useContext, useReducer, useCallback } from 'react';

interface PreferencesState {
  theme: 'light' | 'dark' | 'system';
  locale: string;
  fontSize: number;
  notificationsEnabled: boolean;
  sidebarCollapsed: boolean;
}

type PreferencesAction =
  | { type: 'SET_THEME'; payload: PreferencesState['theme'] }
  | { type: 'SET_LOCALE'; payload: string }
  | { type: 'TOGGLE_NOTIFICATIONS' }
  | { type: 'TOGGLE_SIDEBAR' }
  | { type: 'SET_FONT_SIZE'; payload: number };

function preferencesReducer(
  state: PreferencesState,
  action: PreferencesAction
): PreferencesState {
  switch (action.type) {
    case 'SET_THEME':    return { ...state, theme: action.payload };
    case 'SET_LOCALE':   return { ...state, locale: action.payload };
    case 'TOGGLE_NOTIFICATIONS': return { ...state, notificationsEnabled: !state.notificationsEnabled };
    case 'TOGGLE_SIDEBAR': return { ...state, sidebarCollapsed: !state.sidebarCollapsed };
    case 'SET_FONT_SIZE': return { ...state, fontSize: action.payload };
    default: return state;
  }
}

// Split into two contexts: state (read) and dispatch (write)
// This prevents components that only dispatch from re-rendering when state changes
const PreferencesStateContext = createContext<PreferencesState | undefined>(undefined);
const PreferencesDispatchContext = createContext<React.Dispatch<PreferencesAction> | undefined>(undefined);

const defaultPreferences: PreferencesState = {
  theme: 'system',
  locale: navigator.language,
  fontSize: 16,
  notificationsEnabled: true,
  sidebarCollapsed: false,
};

export function PreferencesProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(preferencesReducer, defaultPreferences);

  return (
    <PreferencesStateContext.Provider value={state}>
      <PreferencesDispatchContext.Provider value={dispatch}>
        {children}
      </PreferencesDispatchContext.Provider>
    </PreferencesStateContext.Provider>
  );
}

export function usePreferences() {
  const ctx = useContext(PreferencesStateContext);
  if (!ctx) throw new Error('usePreferences must be inside PreferencesProvider');
  return ctx;
}

export function usePreferencesDispatch() {
  const ctx = useContext(PreferencesDispatchContext);
  if (!ctx) throw new Error('usePreferencesDispatch must be inside PreferencesProvider');
  return ctx;
}

The Re-render Problem and How to Avoid It

React Context re-renders every consumer when the context value changes. For high-frequency state or contexts consumed by many components, this causes performance problems. The two main strategies:

// Strategy 1: Split state into multiple contexts (preferred)
// Components that only need 'theme' don't re-render when 'fontSize' changes
const ThemeContext = createContext<string>('system');
const FontSizeContext = createContext<number>(16);

// Strategy 2: Memoize the value object (prevents extra re-renders caused by
// object reference changes, but NOT re-renders caused by value changes)
export function PreferencesProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(preferencesReducer, defaultPreferences);

  const value = useMemo(() => ({ ...state, dispatch }), [state]);

  return (
    <PreferencesContext.Provider value={value}>
      {children}
    </PreferencesContext.Provider>
  );
}

Context vs Redux vs Zustand

• Context: Zero dependencies, built into React. Best for low-frequency updates (theme, auth, locale). Every state change re-renders all consumers — a fundamental constraint, not a bug. Fine for ~10 consumers, problematic at ~100.
• Zustand: Selector-based subscriptions mean components only re-render when the specific field they read changes. Zero boilerplate compared to Redux. Best for medium-complexity global state without DevTools requirements.
• Redux Toolkit: Best for large apps, time-travel debugging, complex middleware needs. Higher setup cost but the tooling (Redux DevTools, RTK Query) pays off at scale.

Frequently Asked Questions

Why does the generated hook throw if used outside the Provider? This is intentional — a missing Provider causes subtle runtime bugs that are hard to trace. Throwing with a clear message turns a silent failure into an obvious one. Always wrap your app in the Provider at the appropriate level of your component tree.

Can I use Context with React Server Components? Context is a client-side React feature and cannot be used in React Server Components. For data that originates on the server and needs to reach client components, pass it as props or use a server-side cookie/session store.

Should I initialize context with undefined or a default value? Initializing with undefined and checking in the hook (throwing if not wrapped in Provider) is safer than providing a default — it catches missing Provider wrappers during development. Use a real default only if the context has meaningful values that work without a Provider (e.g., a theme default of 'light').

Is my JSON sent to a server? No. TypeMorph runs entirely in your browser — none of your data leaves your machine.