State Architecture in Modern React: Navigating Server, Client, and URL State

For years, the default answer to state management in React applications was straightforward: install a monolithic global state library (such as Redux, MobX, or early Zustand) and store virtually all application data inside a centralized client-side cache.

Developers routinely stored server API responses, pagination counters, form inputs, modal visibility flags, and search filters together in one massive global object.

With the advent of React Server Components (RSC) (React documentation), Server Functions, streaming hydration, and modern browser routing standards, this monolithic approach has become a major source of friction. Syncing server data with client stores requires thousands of lines of boilerplate, causes cache invalidation nightmares, and balloons client JavaScript bundle sizes.

In modern React, high-performing codebases decompose state into a Four-Tier Architecture: Server State, URL State, Global Client State, and Local Component State (React documentation). In this deep dive, we explore each tier, how to avoid redundant state, and how to select the right tool for each job.

---

The Modern 4-Tier State Taxonomy

Instead of asking "Which state management library should I install?", modern engineering teams ask: "What kind of state is this data?"

┌─────────────────────────────────────────────────────────────┐
│ 1. Server State (Data fetching, caching, mutations)         │
│    └── React Server Components, Server Functions, SWR       │
├─────────────────────────────────────────────────────────────┤
│ 2. URL State (Search filters, pagination, tabs)             │
│    └── URLSearchParams, router navigation, nuqs             │
├─────────────────────────────────────────────────────────────┤
│ 3. Global Client State (Cross-component UI state)           │
│    └── Zustand, Jotai, Context                              │
├─────────────────────────────────────────────────────────────┤
│ 4. Local Component State (Isolated UI interactions)         │
│    └── useState, useReducer, uncontrolled inputs            │
└─────────────────────────────────────────────────────────────┘

---

Tier 1: Server State (Remote Data)

Server State is data that lives in an external database or backend service (e.g. user profiles, blog posts, transaction records).

The Historic Mistake:

Fetching server data via useEffect and copying it into a global Redux/Zustand store. This creates a desynchronized second source of truth:

• Multiple tabs show stale records.
• Refetching and optimistic updates require complex reducer logic.
• The client bundle pays a heavy penalty downloading data-fetching libraries.

The Modern Paradigm:

In React 19, Server Components fetch data directly on the server without shipping fetch code or state containers to the browser:

// Server Component: Server State is fetched directly at the edge
import { db } from '@/lib/db';

export async function ProjectFeed({ teamId }: { teamId: string }) {
  const projects = await db.project.findMany({ where: { teamId } });

  return (
    <div>
      {projects.map(p => (
        <ProjectCard key={p.id} project={p} />
      ))}
    </div>
  );
}

When a user mutates data via a Server Action, React automatically invalidates and re-renders the affected Server Component tree, eliminating client-side cache management entirely.

---

Tier 2: URL State (Navigational & Shareable State)

URL State represents any UI parameter that defines what the user is currently looking at:

• Active search query (?q=react)
• Sorting order (?sort=desc)
• Filter categories (?category=performance)
• Pagination offset (?page=2)
• Active tab (?tab=billing)

Why Global Client State Fails for URL State:

If you store search filters in useState or Zustand:

• Users cannot bookmark or copy-paste the URL to share the view with colleagues.
• Tapping the browser's Back button does not navigate back to the previous search query; it kicks the user off the page.
• Refreshing the browser resets all applied filters to default.

The URL State Solution:

Synchronize navigational filters directly to browser query parameters:

'use client';

import { useSearchParams, useRouter, usePathname } from 'next/navigation';

export function SearchFilter() {
  const searchParams = useSearchParams();
  const pathname = usePathname();
  const { replace } = useRouter();

  function handleSearch(term: string) {
    const params = new URLSearchParams(searchParams);
    if (term) {
      params.set('q', term);
    } else {
      params.delete('q');
    }
    replace(`${pathname}?${params.toString()}`);
  }

  return (
    <input
      defaultValue={searchParams.get('q') || ''}
      onChange={e => handleSearch(e.target.value)}
      placeholder="Filter items..."
    />
  );
}

The URL becomes the single source of truth. Bookmarking, sharing, and browser history work out of the box.

---

Tier 3: Global Client State (Cross-Component UI)

Global Client State is purely client-side data shared across multiple distant components that does not belong in the URL:

• Persistent audio player playback position
• Dark/Light theme mode preferences
• Notification toast queues
• Mobile navigation drawer open/close states

For this tier, keep stores minimal. Lightweight solutions like Zustand or Jotai excel here because they provide atomic subscriptions without the re-render cascades common to un-optimized Context providers.

---

Tier 4: Local Component State (Ephemeral UI)

Local State is temporary data relevant exclusively to a single component or its direct children:

• Text entered in an active comment box before submission
• Hover or active dropdown open states
• Form validation error tooltips

Use standard useState (React documentation), useReducer, or React 19 uncontrolled form actions.

---

Core Architectural Rules: Choosing State Structure

According to the official React documentation on state design (React documentation), adhere to these principles:

1. Don't Put Computed Values into State: If a value can be computed during render from existing props or state, compute it inline:

   // ❌ BAD: Redundant state sync
   const [items, setItems] = useState([]);
   const [totalCount, setTotalCount] = useState(0);
   
   // ✅ GOOD: Derived during render
   const [items, setItems] = useState([]);
   const totalCount = items.length;
   

2. Avoid Contradictory State Flags: Replace boolean flags like isLoading, isError, and isSuccess with a single status state:

   type Status = 'idle' | 'loading' | 'success' | 'error';
   const [status, setStatus] = useState<Status>('idle');
   

3. Lift State Up Only When Needed: Resist the urge to push state into a global store preemptively. Keep state as close to the leaf components consuming it as possible.

---

Conclusion

The era of the all-encompassing monolithic client state store is over. By decomposing data into Server State via Server Components, URL State for shareable parameters, and lean stores for client UI, developers build scalable, resilient React applications that maximize performance while minimizing boilerplate.

---

Sources

• React Learn: Managing State
• React Learn: Choosing the State Structure
• React Reference: useState
• React Reference: Server Components