Global vs Local State

Build the precise mental model for deciding when state earns the right to go global — and learn the measurable cost every unnecessary global state entry imposes on rendering performance, test complexity, and long-term maintainability.

The Application That Re-rendered Everything, All the Time

A fintech startup — three engineers, eighteen months of development — profiled their React application for the first time and found that opening a dropdown menu caused 340 components to re-render. The dropdown affected the display of exactly one. The other 339 re-rendered because they were all subscribed to a global Redux store that contained, among other things, the dropdown's open/closed state. The store had grown organically — one item at a time, each decision locally reasonable — until the application had no concept of local state at all. Everything was global. Everything re-rendered for everything.

That profiling session took four hours. Fixing the architecture took three weeks. The performance improvement was 8× — not through React optimisation techniques, not through memoisation, not through virtual lists, but through moving state to where it actually belonged. Dropdown state inside the dropdown. Form input inside the form. Filter state in the URL. The global store shrunk from 214 entries to 31.

This lesson is about building the mental model that prevents that three-week refactor from ever being necessary — by understanding, precisely and in advance, which state deserves to be global and which doesn't.

The Real Definition of Global State

Global state is not "state that more than one component uses." That definition puts far too much into the global category. It's "state that has no single, stable owner in the component tree — state that must be readable or writable from locations that have no direct hierarchical relationship." Narrowing the definition is the entire practice.

The cost of global state is not free. Every entry in a global store is a new re-render surface — a piece of data that, when it changes, will notify every subscriber in the application. At small scale this is imperceptible. At 200 components subscribing to a store with 100 entries, even disciplined selector usage cannot prevent the compounding cost of unnecessary subscriptions and stale-closure bugs that emerge from components holding references to outdated store slices.

The Four Questions That Determine State Scope

The PixelForge Frontend team runs every new state decision through four diagnostic questions before writing a single line of store code. These questions are not a checklist — they're a reasoning sequence. Each one can terminate the process early with a simpler solution. Global state is only the answer when all four force you there.

Classifying PixelForge State — Global or Local?

Abstract principles only become useful when applied to concrete cases. The following table runs twenty real PixelForge state decisions through the classification. Some are obvious. Several are genuinely surprising — and the surprising ones are where most teams make the wrong call.

The canvas cursor position row is the most instructive. A naïve approach stores cursor position in state so the collaborator presence indicator can show where the user's cursor is. But 60 updates per second through a global store would make the entire application re-render 60 times per second. The correct approach: a useRef tracks the cursor locally with no re-renders, and a throttled WebSocket message broadcasts the position to other collaborators — bypassing React's state system entirely for high-frequency data.

Zustand With Discipline — Slice Design That Prevents Bloat

Zustand is small, fast, and easy to use — which makes it easy to misuse. Its lack of ceremony is a feature and a trap simultaneously. There's no boilerplate discouraging you from adding entries. No architectural constraint preventing you from putting a dropdown's open state in a slice. The discipline has to come from the team, not the library.

The PixelForge Frontend team structures their Zustand store with three explicit rules: every slice entry must survive a three-question audit before it's added, slices are organised by concern not by feature, and components subscribe to the minimum slice they need — never the entire store object.

// WHAT: PixelForge global store — Zustand with disciplined slice design
// Three global-only concerns: auth identity, theme, toast queue
// Everything else lives in local state, React Query, or the URL

import { create } from 'zustand';
import { devtools } from 'zustand/middleware';

// ── Auth slice — changes once per session ──────────────────────────
const createAuthSlice = (set) => ({
  user: null,                          // { id, name, email, planTier }
  workspaceId: null,                   // active workspace — also in URL
  isAuthenticated: false,

  setUser: (user) => set(
    { user, isAuthenticated: true },
    false,
    'auth/setUser'                     // action label for DevTools
  ),
  clearAuth: () => set(
    { user: null, workspaceId: null, isAuthenticated: false },
    false,
    'auth/clearAuth'
  ),
});

// ── Toast slice — cross-feature notification system ────────────────
const createToastSlice = (set, get) => ({
  toasts: [],                          // [{ id, message, type, duration }]

  pushToast: (message, type = 'info', duration = 4000) => set(
    (state) => ({
      toasts: [
        ...state.toasts,
        { id: crypto.randomUUID(), message, type, duration }
      ]
    }),
    false,
    'toast/push'
  ),

  dismissToast: (id) => set(
    (state) => ({ toasts: state.toasts.filter(t => t.id !== id) }),
    false,
    'toast/dismiss'
  ),
});

// ── Combined store ──────────────────────────────────────────────────
export const useStore = create(
  devtools(
    (...args) => ({
      ...createAuthSlice(...args),
      ...createToastSlice(...args),
    }),
    { name: 'PixelForge' }
  )
);

// ── Scoped selectors — components subscribe to minimum needed ───────
export const useUser = () => useStore((s) => s.user);
export const useIsAuthenticated = () => useStore((s) => s.isAuthenticated);
export const useToasts = () => useStore((s) => s.toasts);
export const usePushToast = () => useStore((s) => s.pushToast);

// ── Usage example: archive success toast from ProjectCard ──────────
// const pushToast = usePushToast();
// pushToast('Project archived', 'success');
// → Only ToastRenderer re-renders (the subscriber)
// → ProjectCard does NOT re-render — it's not subscribed to toasts[]

The React Context Performance Trap

React Context is the right tool for genuinely global, infrequently-changing values. It's the wrong tool for most things people use it for. The performance characteristic that makes it dangerous: every component that calls useContext(MyContext) re-renders whenever any part of the context value changes — even if the specific property that component cares about hasn't changed.

A team at Vercel documented this exact issue in their internal dashboard. They had a single AppContext that held user preferences, UI state, and notification data as a single object. Typing a character in a search field updated searchQuery in the context. Every component consuming AppContext — including the user avatar in the corner, the notification badge in the sidebar, the workspace name in the breadcrumb — re-rendered on every keystroke. 47 re-renders per keypress in a search box. The fix was context splitting.

// WHAT: PixelForge — splitting a monolithic AppContext into focused contexts
// Problem: one fat context causes every consumer to re-render on any change
// Solution: separate contexts per concern, each changing at its own frequency

// ── BEFORE — one context, everything re-renders for everything ─────
// const AppContext = createContext({
//   user, theme, toasts, searchQuery, modalOpen, ...
// });
// Problem: typing in search re-renders UserAvatar, ToastRenderer,
//          Sidebar, Breadcrumb — none of which care about searchQuery

// ── AFTER — split by change frequency ──────────────────────────────

// ThemeContext — changes once per session (light/dark toggle)
export const ThemeContext = createContext('light');
export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState(
    () => localStorage.getItem('pf-theme') ?? 'light'
  );
  const value = useMemo(() => ({ theme, setTheme }), [theme]);
  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

// AuthContext — changes once per session (sign in/out)
export const AuthContext = createContext(null);
export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const value = useMemo(() => ({ user, setUser }), [user]);
  return (
    <AuthContext.Provider value={value}>
      {children}
    </AuthContext.Provider>
  );
}

// Search state — changes on every keystroke; does NOT go in context
// Lives in useState inside the SearchBar component — no other component
// needs the draft query value until the user submits
export function SearchBar() {
  const [query, setQuery] = useState('');          // local, not context
  const { data } = useQuery({
    queryKey: ['search', query],
    queryFn: () => api.get(`/search?q=${query}`),
    enabled: query.length > 2,
  });
  return <input value={query} onChange={e => setQuery(e.target.value)} />;
}

State Colocation — The Simplest Principle With the Biggest Impact

State colocation is the practice of keeping state as close as possible to the components that use it. It is the single most impactful state management principle in everyday front end engineering — and the least glamorous, because it doesn't require a new library or a new architectural pattern. It just requires consistently asking: could this state live lower in the tree?

Kent C. Dodds, who coined the term "state colocation" as a formal practice, measured the impact on a medium-complexity React application and found that moving state from a page-level component to the leaf components that used it reduced the average re-render count per user interaction from 18.3 to 3.1 — without any memoisation, without any store changes, without any performance optimisation tooling. Just moving state to where it was actually needed.

The PixelForge Frontend team's monthly architecture review includes a "state audit" pass over any component file that was modified more than five times in the last month. High-churn files often indicate that state responsibilities have drifted — state that started local has been lifted without justification, or global state that was added for convenience is being read in components that have no business knowing about it. The audit takes one hour and consistently surfaces two or three relocations that reduce re-render counts by 20–40% in the affected area of the application.

Quiz