Declarative UI means describing all possible states—idle, loading, success, error. Describe what each state looks like, and React handles the transitions.

Concepts Applied: Declarative programming, State as single source of truth, Immutability (new state objects trigger re-renders)

import { useState, useEffect } from 'react'

type Status = 'idle' | 'loading' | 'success' | 'error'

function ProductList() {
  const [status, setStatus] = useState<Status>('idle')
  const [products, setProducts] = useState([])
  const [error, setError] = useState(null)

  useEffect(() => {
    async function loadProducts() {
      setStatus('loading')

      try {
        const response = await fetch('/api/products')
        if (!response.ok) throw new Error('Failed to fetch')

        const data = await response.json()
        setProducts(data)
        setStatus('success')
      } catch (err) {
        setError(err.message)
        setStatus('error')
      }
    }

    loadProducts()
  }, [])

  // Declarative rendering: describe each state
  if (status === 'loading') return <p>Loading...</p>
  if (status === 'error') return <p>Error: {error}</p>

  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>{p.name} - ${p.price}</li>
      ))}
    </ul>
  )
}

Why declarative states win: You describe what each state looks like. State is the single source of truth—check status === 'loading', not the DOM. Immutability enables transitions: setStatus('loading') creates a new value, React detects change, re-renders.

Alternative: Type-safe discriminated unions

type State =
  | { status: 'loading' }
  | { status: 'success'; data: Product[] }
  | { status: 'error'; error: string }

const [state, setState] = useState<State>({ status: 'loading' })

switch (state.status) {
  case 'loading': return <Skeleton />
  case 'error': return <Error message={state.error} />
  case 'success': return <List items={state.data} />
}

The Aha Moment: “Declarative UI (Section 1) means describing states, not transitions. State is the source of truth (Section 2). Immutability (Section 1) makes React detect changes and re-render.”

Empty dependencies [] run once on mount. Specified dependencies make effects reactive—when props, state, or URL params change, effects re-run and refetch data.

When you need this: Search interfaces (refetch when query changes), filtered product lists (refetch when category/price changes), tabbed content (fetch data for active tab), pagination (fetch new page on click), master-detail views (fetch details when user selects item)—any time data needs to update based on user interaction or URL changes.

Concepts Applied: Effect dependencies (when to re-run), Cleanup functions (prevent race conditions), URL state integration, Stale closures

import { useState, useEffect } from 'react'
import { useSearchParams } from 'react-router-dom'

function SearchResults() {
  const [searchParams] = useSearchParams()
  const query = searchParams.get('q') || ''

  const [results, setResults] = useState([])
  const [loading, setLoading] = useState(false)

  useEffect(() => {
    const controller = new AbortController()

    async function fetchResults() {
      setLoading(true)
      try {
        const response = await fetch(
          `/api/search?q=${query}`,
          { signal: controller.signal }
        )
        const data = await response.json()
        setResults(data)
      } catch (error) {
        if (error.name !== 'AbortError') {
          console.error('Fetch failed:', error)
        }
      } finally {
        setLoading(false)
      }
    }

    fetchResults()
    return () => controller.abort()  // Cleanup
  }, [query]) // Re-run when query changes

  return <ul>{results.map(item => <li key={item.id}>{item.title}</li>)}</ul>
}

Why dependencies matter: URL changes from ?q=react to ?q=vue → query changes → effect re-runs → fetch new results. Cleanup prevents race conditions: if user types “vue” before “react” fetch completes, cleanup cancels the “react” fetch.

Common patterns:

// Debounced fetching (avoid fetch on every keystroke)
const [searchTerm, setSearchTerm] = useState('')
const [debouncedTerm, setDebouncedTerm] = useState('')

useEffect(() => {
  const timer = setTimeout(() => setDebouncedTerm(searchTerm), 300)
  return () => clearTimeout(timer)
}, [searchTerm])

useEffect(() => {
  if (debouncedTerm) fetchResults(debouncedTerm)
}, [debouncedTerm])

// Race condition handling with ignore flag
useEffect(() => {
  let ignore = false

  async function fetchData() {
    const data = await fetch(`/api/data/${id}`).then(r => r.json())
    if (!ignore) setData(data)
  }

  fetchData()
  return () => { ignore = true }
}, [id])

The Aha Moment: “Dependencies (Section 3) make effects reactive. URL state (Section 2) drives fetching. Cleanup (Section 3) prevents race conditions. Reactive data flow: URL changes → deps change → effect re-runs → new data.”

Component state doesn’t scale when multiple components need the same data. Global state (Zustand) centralizes fetching logic and data storage. Selectors enable efficient subscriptions—components only re-render when their specific slice changes.

When you need this: Shopping carts accessed across pages, user authentication state (profile shown in header, sidebar, settings), global notifications/toasts, theme settings (dark mode toggle), chat messages shared between sidebar and main view, currently selected items in multi-page workflows—any time multiple components across your app need the same data.

Concepts Applied: Global state (Zustand patterns), Selectors for efficient subscriptions, Separation of concerns, Server as data source

import { create } from 'zustand'

// Define store with async actions
const useUserStore = create((set, get) => ({
  users: [],
  loading: false,
  error: null,

  fetchUsers: async () => {
    set({ loading: true, error: null })

    try {
      const users = await fetch('/api/users').then(r => r.json())
      set({ users, loading: false })  // Immutable update
    } catch (error) {
      set({ error: error.message, loading: false })
    }
  },

  createUser: async (userData) => {
    const newUser = await fetch('/api/users', {
      method: 'POST',
      body: JSON.stringify(userData)
    }).then(r => r.json())

    // Immutable array update
    set(state => ({ users: [...state.users, newUser] }))
    return newUser
  }
}))

// Component usage with selectors
function UserList() {
  const users = useUserStore(state => state.users)
  const fetchUsers = useUserStore(state => state.fetchUsers)

  useEffect(() => { fetchUsers() }, [fetchUsers])

  return (
    <ul>
      {users.map(user => <li key={user.id}>{user.name}</li>)}
    </ul>
  )
}

Why global state scales: No prop drilling—components access the store directly. Selectors prevent unnecessary re-renders: UserList subscribes to state.users, so when currentUser updates, UserList doesn’t re-render. Centralized fetching logic in the store. State persists across component unmounts.

Advanced: Derived state with selectors

// Compute filtered users in selector
const filteredUsers = useUserStore(state =>
  state.users.filter(user =>
    user.name.toLowerCase().includes(state.searchTerm.toLowerCase())
  )
)

// Use shallow equality for expensive computations
import { shallow } from 'zustand/shallow'

const user = useUserStore(
  state => ({ name: state.name, email: state.email }),
  shallow
)

The Aha Moment: “Global state (Section 2) solves prop drilling. Selectors (Section 3) prevent re-renders. Immutability (Section 1) still applies—set() creates new state objects. Fetching logic moves to the store.”

Network requests are slow. Caching solves this: store data in localStorage, show it instantly (stale), fetch fresh data in background (revalidate).

When you need this: Slow API endpoints (external services, complex database queries), frequently accessed data that doesn’t change often (product catalogs, user directories), offline-first applications, reducing API costs and rate limits, news feeds where instant load matters more than showing the absolute latest—any time perceived performance beats waiting for fresh data.

Concepts Applied: Persistence (localStorage + Zustand), Hydration timing, Immutability (comparing cached vs fresh data), Advanced state patterns

import { create } from 'zustand'
import { persist } from 'zustand/middleware'

const useProductStore = create(
  persist(
    (set, get) => ({
      products: [],
      lastFetch: null,

      // Stale-while-revalidate pattern
      fetchProducts: async () => {
        const cached = get().products

        // Show cached data immediately
        if (cached.length > 0) {
          set({ products: cached })
        }

        // Fetch fresh in background
        const fresh = await fetch('/api/products').then(r => r.json())

        // Compare with immutability check
        const hasChanged = JSON.stringify(fresh) !== JSON.stringify(cached)
        if (hasChanged) {
          set({ products: fresh, lastFetch: Date.now() })
        }
      }
    }),
    { name: 'product-cache' }
  )
)

Why this works: User opens page → Zustand hydrates from localStorage → cached data shows instantly → fresh fetch happens in background. Immutability enables smart updates: only update if data actually changed.

Cache invalidation strategies:

// Time-based (TTL)
fetchWithTTL: async () => {
  const lastFetch = get().lastFetch
  const FIVE_MINUTES = 5 * 60 * 1000

  if (lastFetch && (Date.now() - lastFetch) < FIVE_MINUTES) {
    return  // Cache fresh, skip fetch
  }

  const data = await fetch('/api/data').then(r => r.json())
  set({ data, lastFetch: Date.now() })
}

// Invalidate on mutation
createProduct: async (newProduct) => {
  await fetch('/api/products', { method: 'POST', body: JSON.stringify(newProduct) })
  set({ products: [], lastFetch: null })
  await get().fetchProducts()
}

The Aha Moment: “Hydration (Section 2) is how caching works. Persist middleware handles hydration timing. Immutability (Section 1) enables change detection. Stale-while-revalidate gives instant loads + fresh data.”

Production applications combine every pattern: pure functions transform data, immutability enables optimistic updates, effects manage polling, cleanup prevents leaks.

When you need this: Chat applications (polling for new messages, optimistic message sending), collaborative editing tools (real-time updates, conflict resolution), social feeds (polling for new posts, infinite scroll with deduplication), live dashboards (real-time metrics), form submissions with instant feedback, e-commerce checkout (retry logic, handling network failures)—any application where users expect real-time updates and instant responsiveness.

Concepts Applied: ALL previous concepts—FP principles (Section 1), all data source patterns (Section 2), all lifecycle and effect patterns (Section 3)

Pattern 1: Polling with cleanup

function LiveMessages() {
  const fetchMessages = useMessageStore(state => state.fetchMessages)

  useEffect(() => {
    fetchMessages()  // Initial

    const interval = setInterval(fetchMessages, 5000)
    return () => clearInterval(interval)  // Cleanup on unmount
  }, [fetchMessages])

  return <MessageList />
}

Pattern 2: Optimistic updates with rollback

const useMessageStore = create((set, get) => ({
  messages: [],

  sendMessage: async (text) => {
    const tempId = `temp-${Date.now()}`
    const optimisticMsg = { id: tempId, text, pending: true }

    // Immediate UI update (immutability)
    set(state => ({ messages: [...state.messages, optimisticMsg] }))

    try {
      const serverMsg = await fetch('/api/messages', {
        method: 'POST',
        body: JSON.stringify({ text })
      }).then(r => r.json())

      // Replace temp with real
      set(state => ({
        messages: state.messages.map(msg =>
          msg.id === tempId ? serverMsg : msg
        )
      }))
    } catch (error) {
      // Rollback: remove failed message
      set(state => ({
        messages: state.messages.filter(msg => msg.id !== tempId)
      }))
    }
  }
}))

Pattern 3: Data normalization (pure function)

// Normalize nested data by ID
function normalize(users) {
  const usersById = {}
  const postsById = {}

  users.forEach(user => {
    const postIds = user.posts.map(post => {
      postsById[post.id] = post
      return post.id
    })
    usersById[user.id] = { ...user, posts: postIds }
  })

  return { usersById, postsById }
}

// Store normalized data
const useStore = create((set) => ({
  usersById: {},
  postsById: {},

  fetchUsers: async () => {
    const users = await fetch('/api/users').then(r => r.json())
    const { usersById, postsById } = normalize(users)
    set({ usersById, postsById })
  },

  // Easy immutable update!
  updatePost: (postId, updates) => {
    set(state => ({
      postsById: {
        ...state.postsById,
        [postId]: { ...state.postsById[postId], ...updates }
      }
    }))
  }
}))

Pattern 4: Request deduplication

const useStore = create((set, get) => ({
  inflightRequests: new Set(),

  fetchUsers: async () => {
    if (get().inflightRequests.has('fetch-users')) return

    set(state => ({
      inflightRequests: new Set(state.inflightRequests).add('fetch-users')
    }))

    try {
      const users = await fetch('/api/users').then(r => r.json())
      set({ users })
    } finally {
      set(state => {
        const newSet = new Set(state.inflightRequests)
        newSet.delete('fetch-users')
        return { inflightRequests: newSet }
      })
    }
  }
}))

The Aha Moment: “Every pattern combines concepts. Purity (Section 1) transforms/normalizes data. Immutability (Section 1) enables optimistic updates and rollbacks. Effects + cleanup (Section 3) manage polling and timers. Global state + selectors (Sections 2-3) coordinate everything. This is production React—composition of fundamental principles.”