# React, Inside Out: A Guided Q&A Journey from First Render to Production ## Part 1: Why This Guide (and How to Use It) Most “React questions” posts feel like flash cards. You skim 30 answers, nod along, and forget them by tomorrow. This guide is different. It’s a **guided learning path**: each question builds on the last, moving from fundamentals to production-grade patterns. You’ll get **plain-English answers, runnable code, and “why it matters” notes** that tie concepts to real bugs and real apps. ### What you’ll get out of this series - A mental model of React that holds up under pressure (not just trivia). - Production-aware answers: performance, accessibility, DX, testing. - Progressive questions from beginner → expert, so you always know what to learn next. --- ## A Quick Story (a.k.a. The Hook) You build a list of editable items. Everything works, until you delete the second item and **the cursor jumps** to another input. Users complain “your app is haunted.” What happened? ```jsx // ❌ Buggy: index as key causes React to reuse DOM nodes incorrectly function TodoList({ todos, onChange }) { return (

onChange(i, e.target.value)} />

); } ``` **Why it breaks:** React uses `key` to match previous and next children. With `key={i}`, deleting an item shifts indexes; React reuses the wrong DOM node, so the cursor and value “jump.” **The fix: stable keys.** ```jsx // ✅ Correct: stable, unique keys tied to identity function TodoList({ todos, onChange }) { return (

onChange(todo.id, e.target.value)} />

); } ``` **Why this matters:** This isn’t just a “keys” question. It’s a window into **how React reconciles** UI. Understand this, and you debug categories of bugs (focus thrash, animation glitches, stale state) before they ship. This series is full of questions like that: **small surface, big leverage**. --- ## How this guide works Each part (and each question inside a part) follows the same pattern: 1) **The Question:** phrased as you’d see it in interviews or code reviews. 2) **The Answer:** clear and direct, in plain English. 3) **Code:** a minimal, runnable example (buggy first when useful, then fixed). 4) **Why it Matters:** the real-world context: perf, DX, a11y, testing, and trade-offs. 5) **Level Up:** optional prompts to push the idea further. You can read straight through, or jump to sections you need. --- ## The Path (from Basics to Advanced) We’ll progress in layers. Each layer contains 6–10 high-impact questions. 1. **Foundations** *JSX, rendering, components, props vs state, events, one-way data flow.* 2. **State & Effects** *`useState`, `useEffect`, dependency arrays, derived state, lifting state up, controlled vs uncontrolled.* 3. **Lists, Keys & Forms** *Stable identity, form patterns, validation, debouncing, refs.* 4. **Data Fetching & Async** *Promises, race conditions, cancellation, `useEffect` pitfalls, SWR/React Query mental models.* 5. **Performance** *Re-renders, memoization (`React.memo`, `useMemo`, `useCallback`), virtualization, code splitting.* 6. **Context & State Management** *Context anti-patterns, selectors, when to reach for Redux/Zustand/Jotai, colocation.* 7. **Routing & Architecture** *Nested layouts, data loaders/actions (framework-dependent insights), error boundaries, layout effects.* 8. **Advanced React** *Suspense, concurrent rendering concepts, transitions, streaming, server components (framework notes).* 9. **Testing & Accessibility** *Testing Library mindset, mocking fetch, user flows; a11y roles, focus management, keyboard traps.* 10. **Patterns & Smarter Components** *Compound components, render props vs hooks, headless UI patterns, inversion of control.* Each part will have curated questions (**not** a brain dump), chosen for maximum ROI. --- ## What to expect next (Part 2 preview) We’ll start at the beginning, with **Foundations**. Expect questions like: - *What is JSX really?* - *What triggers a re-render?* - *Props vs state: how do you choose?* - *Why do event handlers “see” stale values sometimes?* You’ll get concise answers with code and “why it matters” so you can **use the knowledge immediately**. --- ## Level Up: How to Get the Most Out of This Series - **Run the code**: Recreate snippets in StackBlitz/CodeSandbox. Break them on purpose. - **Write the “why”**: After each question, jot down your own “why it matters” in one sentence. - **Translate**: Turn an answer into a code review comment you could leave for a teammate. - **Compare & contrast**: For every fix, ask what trade-offs it introduces (perf, complexity, DX). --- ## TL;DR - This is a **guided Q&A**, not trivia. - You’ll learn **how React thinks**, not just how API calls work. - Every question includes **code** and **context** so it sticks. **Ready?** Let’s start with the foundations and build up, carefully, deliberately, and with code you can ship. > Next up: **Part 2: Foundations: JSX, Rendering & Component Basics** --- # Part 2: Foundations: JSX, Rendering & Component Basics This section lays the groundwork: **what JSX really is**, how React **renders and re-renders**, what counts as a **component**, and the **rules of props vs state**. Each Q&A includes code and “why it matters” so you can ship better UI with fewer surprises. --- ## 1) What is JSX, really? **Answer (plain English):** JSX is **syntax sugar** that compiles to `React.createElement(type, props, ...children)`. It’s not HTML; it’s JavaScript expressions that produce **plain objects** (React elements) describing what you want on screen. **Code: JSX vs createElement** ```jsx // JSX const view = ; // Roughly equivalent const view2 = React.createElement( "button", { className: "primary" }, "Click" ); ``` **Why it matters:** JSX is just JavaScript. That’s why you can use **conditionals**, **loops**, and **expressions** inside it, and why **attributes** use `camelCase` (`className`, `onClick`) instead of HTML attribute names. **Level up:** Add TypeScript types to prop objects. JSX will enforce them. --- ## 2) What triggers a render in React? **Answer:** A component (function) runs when: 1. Its **state** changes (via `setState`/`useState`). 2. Its **props** change (parent re-renders with new props identity). 3. Its **context** value (that it reads) changes. 4. Its **parent re-renders** and passes unchanged props (component still runs; memoization can prevent). **Code (state triggers render):** ```jsx function Counter() { const [count, setCount] = React.useState(0); console.log("render", count); return ; } ``` **Why it matters:** Knowing render triggers helps you **avoid accidental re-renders**, choose when to **memoize**, and structure data flow correctly. **Level up:** Use `React.memo` to skip renders when props are referentially equal. --- ## 3) Props vs State: Which Should I Use? **Answer:** - **Props** are **inputs** from a parent; the component **does not own** them (read-only). - **State** is **owned** by the component; it represents **mutable, local UI data** that changes over time. **Code:** ```jsx function Greeting({ name }) { // name is a prop: external input const [expanded, setExpanded] = React.useState(false); // state: internal UI return (

Hello, {name}

{expanded &&

Welcome to the app!

}

); } ``` **Why it matters:** Putting data in the wrong place causes **prop drilling**, **stale UI**, and **duplicated sources of truth**. A good rule: **If multiple components need to read/change it, lift the state up** to their closest common parent (or a store). **Level up:** Treat **derived data** (e.g., `items.length`) as derived. Don’t store it in state. --- ## 4) How does React decide what to update in the DOM? **Answer:** React builds a **new tree of elements** from your render, compares it with the previous tree (**reconciliation**), and applies the **minimal DOM mutations**. Keys influence how list children are matched; stable keys = stable DOM identity. **Code (list identity):** ```jsx function TodoList({ todos }) { return (

{todo.text}

); } ``` **Why it matters:** Correct keys prevent **focus jumps**, **animation glitches**, and **state leaks** within list items. Reconciliation is why React is fast and predictable when you respect identity. **Level up:** Use **stable IDs** from your data model; avoid array index as a key except for static lists. --- ## 5) How do event handlers work in React? **Answer:** You pass a function (closure) to an event prop like `onClick`. React **does not call the function immediately**. It stores it and calls it **later** on user interaction. Handlers “capture” variables from their render. **Code (closures & stale values):** ```jsx function DelayedCounter() { const [count, setCount] = React.useState(0); function handleClick() { setTimeout(() => { // This closure sees the *latest* state because we use functional update: setCount(c => c + 1); }, 500); } return ( ); } ``` **Why it matters:** If your handler uses **stale variables** from an older render, you can get bugs. Prefer **functional state updates** (`setCount(c => c + 1)`) when next value depends on the previous. **Level up:** For expensive handlers passed to children, memoize with `useCallback` to keep function identity stable. --- ## 6) Controlled vs Uncontrolled inputs: Which and Why? **Answer:** - **Controlled:** React owns the value; input’s `value` comes from state, and `onChange` updates state. - **Uncontrolled:** The DOM owns the value; you read with a **ref** when you need it. **Controlled (best for validation + instant UI coherence):** ```jsx function NameForm() { const [name, setName] = React.useState(""); return ( setName(e.target.value)} placeholder="Your name" /> ); } ``` **Uncontrolled (quick + simple, less React overhead):** ```jsx function NameFormUncontrolled() { const ref = React.useRef(null); function handleSubmit() { alert(ref.current?.value); } return ( <> ); } ``` **Why it matters:** Controlled inputs give you **single source of truth** and easy validation; uncontrolled can be **simpler** and avoids re-rendering on every keystroke. **Level up:** For large forms, consider **hybrid** approaches (controlled on blur, uncontrolled on input), or use a form library. --- ## 7) When should I use `useState` vs derive during render? **Answer:** Use `useState` **only** for data that changes over time and is **not derivable** from props/state. If you can compute it during render without losing information, **derive it** instead of storing. **Code (derived, not state):** ```jsx function CartSummary({ items }) { const total = items.reduce((sum, it) => sum + it.price * it.qty, 0); // derived return

Total: ${total.toFixed(2)}

; } ``` **Why it matters:** Avoids **double sources of truth**, removes **sync bugs**, and reduces state surface area. **Level up:** When derivation is expensive, memoize with `useMemo` (but only after measuring). --- ## 8) Why do we talk so much about “identity” in React? **Answer:** React’s reconciliation relies on **object identity** (===). If you create **new object/array/function instances** each render, children that depend on shallow comparisons may **re-render needlessly**. **Code (stable vs unstable props):** ```jsx function Parent({ items }) { // ❌ new array each render => children re-render // const selected = items.filter(x => x.selected); // ✅ memoize derived data by input identity const selected = React.useMemo( () => items.filter(x => x.selected), [items] ); return ; } ``` **Why it matters:** Stable identities help **`React.memo`**, **`useEffect` deps**, and **performance**. It’s the backbone of predictable diffing. **Level up:** Stabilize callbacks (`useCallback`) and large objects you pass down frequently. --- ## Quick Checklist (Foundations) - JSX → `createElement` → element objects → DOM via reconciliation - Render triggers: state, props, context, parent renders - Props (inputs) vs state (owned, mutable UI data) - Lists need **stable keys** (identity) - Event handlers are closures. Prefer functional updates when needed - Controlled vs uncontrolled inputs: pick based on validation and performance - Derive when possible; store only non-derivable, time-varying data - Identity stability unlocks perf and correctness --- ### Up Next: Part 3: State & Effects (the power duo) We’ll dig into **`useState`** patterns, **`useEffect`** gotchas, **dependency arrays**, **race conditions**, **cancellation**, and when to **lift state up**. Expect bug-first examples, then fixes, with “why it matters” every time. --- # Part 3: State & Effects: The Power Duo State and effects are the **engine room of React**. State drives **data over time**, and effects let you **synchronize** with the outside world (APIs, DOM, timers). Used wisely, they give you power. Used carelessly, they create bugs that feel like black magic. --- ## 1) What are the different types of state in React? **Answer:** React state isn’t just `useState`. You’ll usually deal with three categories: 1. **Local UI state** (e.g., toggling a dropdown, tracking form input). ```jsx const [isOpen, setIsOpen] = React.useState(false); ``` 2. **Derived state** (computed from props or other state; avoid storing it). ```jsx const total = items.reduce((sum, it) => sum + it.qty * it.price, 0); ``` 3. **Global/shared state** (needed across multiple components; may require lifting state up or using Context, Redux, Zustand, etc.). **Why it matters:** Correct classification avoids **state duplication** and **sync bugs**. For example: Don’t store `fullName` if you already have `firstName` + `lastName`. --- ## 2) Why do we use `useEffect`? **Answer:** `useEffect` is for running **side effects** after React has painted the screen: - Data fetching - Subscribing/unsubscribing (WebSocket, events) - Manually manipulating DOM - Syncing to external systems (localStorage, analytics) **Code: data fetch** ```jsx function Users() { const [users, setUsers] = React.useState([]); React.useEffect(() => { fetch("/api/users") .then(r => r.json()) .then(setUsers); }, []); // run once on mount return

{u.name}

; } ``` **Why it matters:** Effects are React’s bridge to “the world outside React.” Keeping them clean avoids **memory leaks**, **duplicated fetches**, and **race conditions**. --- ## 3) How do dependency arrays work? **Answer:** The dependency array tells React **when to re-run the effect**. - `[]` → run once (on mount + cleanup on unmount). - `[value]` → run whenever `value` changes. - **Omit array** → run after every render. **Code:** ```jsx useEffect(() => { console.log("runs every time 'id' changes"); }, [id]); ``` **Why it matters:** Incorrect deps = bugs: - Missing dep → stale values, wrong behavior. - Extra dep → unnecessary re-runs. **Pro tip:** React’s ESLint plugin will warn you if you miss something. --- ## 4) How do you clean up effects? **Answer:** Return a **cleanup function** inside `useEffect`. React runs it: - Before re-running the effect - When the component unmounts **Code:** ```jsx useEffect(() => { const id = setInterval(() => console.log("tick"), 1000); return () => clearInterval(id); // cleanup }, []); ``` **Why it matters:** Without cleanup, you leak timers, subscriptions, or event listeners → **memory leaks** and **duplicate work**. --- ## 5) How do we avoid race conditions in effects? **Answer:** If you fire async requests in an effect, a slow response can overwrite a faster one. Prevent by: - Using **AbortController** to cancel - Tracking an **“ignore” flag** **Code:** ```jsx useEffect(() => { const controller = new AbortController(); fetch(`/api/item/${id}`, { signal: controller.signal }) .then(r => r.json()) .then(data => setItem(data)) .catch(err => { if (err.name !== "AbortError") throw err; }); return () => controller.abort(); }, [id]); ``` **Why it matters:** Without cancellation, your UI may show **stale data** from an outdated request. --- ## 6) When should I lift state up vs use context? **Answer:** - **Lift state up** if just 2–3 sibling components need it. - **Context** if state is needed **deeply across many levels**. **Code (lifting state up):** ```jsx function App() { const [dark, setDark] = useState(false); return ( <> setDark(d => !d)} /> ); } ``` **Code (context):** ```jsx const ThemeContext = React.createContext("light"); function App() { return ( ); } ``` **Why it matters:** Right placement of state makes your code **simpler and easier to reason about**. Wrong placement = **prop drilling** or **unnecessary renders**. --- ## 7) What about `useReducer` vs `useState`? **Answer:** - Use **`useState`** for simple toggles, counters, forms. - Use **`useReducer`** for complex state with multiple transitions. **Code (useReducer):** ```jsx function Counter() { const [state, dispatch] = React.useReducer((s, action) => { switch (action.type) { case "inc": return { count: s.count + 1 }; case "dec": return { count: s.count - 1 }; default: return s; } }, { count: 0 }); return ( <> {state.count} ); } ``` **Why it matters:** Reducers centralize logic, make state transitions explicit, and are easier to test. --- ## 8) Common mistakes with state & effects - ❌ **Storing derived data** (e.g., `const [length, setLength] = useState(items.length)`). - ❌ **Forgetting cleanup** (`setInterval`, event listeners). - ❌ **Overusing context** (causes whole tree to re-render). - ❌ **Triggering effects with wrong deps** (stale data or infinite loops). - ❌ **Async directly in effect body** (instead, use async function inside). --- ## Quick Checklist (State & Effects) - `useState` → local, simple data - `useReducer` → complex state transitions - Effects run **after paint**, cleanup prevents leaks - Dependency arrays control re-run timing - Cancel async requests to prevent race bugs - Lift state up when local isn’t enough; Context when scaling wider - Avoid storing derivable values --- ### Up Next: Part 4: Rendering Performance & Memoization We’ll cover **why React re-renders so much**, how to **measure and profile**, when to use **`React.memo`**, **`useMemo`**, **`useCallback`**, and strategies for scaling performance in big apps without premature optimization. --- # Part 4: Rendering Performance & Memoization React is **fast by default**. It reconciles virtual DOM changes efficiently. But as your app grows, re-renders can pile up, and performance issues appear. Knowing *why* React re-renders and *how* to optimize when necessary is key to keeping your UI smooth. --- ## 1) Why does React re-render? **Answer:** A component re-renders when: 1. **Its state changes** 2. **Its props change** 3. **Its parent re-renders** (and passes new props) Re-renders are **not inherently bad**. React is optimized to make them cheap. Problems arise when: - You have **expensive components** (large lists, complex DOM). - You trigger **unnecessary renders** (e.g., same props but re-created functions/objects). --- ## 2) What tools help us profile performance? - **React DevTools Profiler:** Shows re-renders, render times, “wasted” renders. - **Why Did You Render** (community lib): Warns when components re-render with identical props. - **Browser DevTools:** Measure JS execution, paint times. **Why it matters:** Optimization should be **measured, not guessed**. Premature optimization is often wasted effort. --- ## 3) What is `React.memo`? **Answer:** `React.memo` is a higher-order component that memoizes the **render output**. If props are shallowly equal, React skips re-rendering. ```jsx const Button = React.memo(function Button({ onClick, label }) { console.log("Rendered!"); return ; }); ``` ```jsx ); } // Usage: First Second Third ``` **Why it matters:** - Enables flexible APIs. - Parent shares state automatically. - Children stay declarative. This is how many UI libraries (Material UI, Chakra UI, Radix UI) structure their components. --- ## 4) What’s a render prop vs a custom hook? - **Render prop**: Passing a function as a child for reusable logic. ```jsx {pos =>

X: {pos.x}, Y: {pos.y}

} ``` - **Custom hook**: Encapsulates logic without extra nesting. ```jsx const { x, y } = useMouse();

X: {x}, Y: {y}

``` **Why hooks win:** Hooks avoid “prop drilling hell” and keep JSX cleaner, though render props still have niche uses. --- ## 5) How do hooks enable inversion of control? Hooks let you **invert control of logic** away from components: - Without hooks → UI controls logic. - With hooks → logic is extracted, UI just “plugs into” it. This makes your components thinner, and your hooks reusable. --- ## 6) Patterns to know - **State Reducer Pattern:** Share complex state machines across components. - **useReducer + Context:** Mini Redux inside your app. - **Context Module Pattern:** Split big context providers into smaller, more focused ones. - **Hook Factories:** Hooks that generate other hooks with preconfigured behavior. --- ## Key Takeaways - Custom hooks are your **logic Lego blocks**. - Controlled vs uncontrolled inputs matter most in **forms** and **validation**. - Compound components = flexible, scalable APIs for UI kits. - Prefer custom hooks over render props for cleaner code. - Hooks let you **separate logic from UI**, leading to better maintainability. --- ### Up Next: Part 6: Context, State Management & Beyond React hooks are great for local state. But what happens when multiple components need to **share state**? That’s where **Context**, **reducers**, and **state libraries** come into play. Next, we’ll tackle that head-on. --- # Part 6: Context, State Management & Beyond At some point, your app grows beyond “a few components.” Suddenly, you have **data that many components need to access**: authentication, theme, user preferences, shopping carts, notifications… How do you share this without passing props through 5 layers of components? That’s where **Context** and **state management patterns** come in. --- ## 1) What is React Context? **Answer:** Context is React’s built-in way of sharing state across the component tree without prop drilling. ```jsx const ThemeContext = React.createContext("light"); function App() { return ( ); } function Toolbar() { return ; } function ThemedButton() { const theme = React.useContext(ThemeContext); return ; } ``` **Why it matters:** - Avoids prop drilling. - Centralizes shared state. - Useful for things like authentication, theming, localization. But: **Context is not a replacement for all state management**. It’s great for relatively static or medium-sized data. --- ## 2) When should you use Context vs props? - **Props**: Best for localized state, especially when only a few components need it. - **Context**: Best when many components need the same data, and passing props becomes cumbersome. Rule of thumb: **Start with props. Reach for context only when needed.** --- ## 3) What about `useReducer`? For complex local state with many transitions, `useReducer` can replace `useState`. ```jsx function cartReducer(state, action) { switch (action.type) { case "add": return [...state, action.item]; case "remove": return state.filter(i => i.id !== action.id); default: return state; } } function Cart() { const [cart, dispatch] = useReducer(cartReducer, []); return (

{JSON.stringify(cart)}

); } ``` **Why it matters:** - Makes state transitions explicit. - Pairs perfectly with Context → **Context + useReducer = global state manager**. --- ## 4) Context + Reducer Pattern Combine `useReducer` with `Context` to build a mini Redux-like state manager. ```jsx const CartContext = React.createContext(null); function CartProvider({ children }) { const [state, dispatch] = useReducer(cartReducer, []); return ( {children} ); } function CartButton() { const { dispatch } = useContext(CartContext); return ; } ``` **Why it matters:** - Scales well for medium apps. - No need for external libraries yet. - Testable, explicit, predictable. --- ## 5) When do you need external libraries (Redux, Zustand, Jotai, Recoil)? **Context + Reducer works until:** - You have **lots of contexts** → “provider hell.” - Performance bottlenecks → too many components re-render. - Async workflows → more complex than reducers alone. At that point, you may want external libraries: - **Redux Toolkit** → explicit, strict patterns, great for large apps. - **Zustand** → minimal boilerplate, store-based. - **Jotai** → atomic, composable state. - **Recoil** → declarative graph of state dependencies. Each balances **boilerplate vs control vs performance**. --- ## 6) Beyond State: Query Libraries (React Query, Apollo) Not all state is app state! Some is **server state** (fetched from APIs). - **React Query (TanStack Query):** Handles caching, background updates, retries, pagination. - **Apollo Client:** Similar but focused on GraphQL. Rule: Use React state for local data, **query libraries for server data**. --- ## 7) Why not just use one giant Context? Because: - Every consumer re-renders on any value change. - Can hurt performance if you store large/fast-changing state. ✅ Solution: Split into **multiple contexts** or use libraries that optimize updates. --- ## Key Takeaways - **Props first** → Context only when prop drilling becomes painful. - **useReducer** makes complex state predictable. - **Context + Reducer = mini global state management.** - For bigger apps: reach for **Redux, Zustand, Jotai, Recoil**. - For async/server data: **React Query or Apollo**. - Avoid giant contexts. Split or optimize. --- ### Up Next: Part 7: Performance Optimization & Scaling Managing state is one thing, but making sure your app **stays fast** as it grows is another. Next, we’ll dive into **memoization, virtualization, and performance tricks** that separate “it works” code from production-ready React apps. --- # Part 7: Precision Performance: `useMemo`, `useCallback`, and `Suspense` React is fast, but **re-render churn** and **expensive calculations** can still bite. This section goes deep on **memoization** (`useMemo`, `useCallback`) and **coordination** (`Suspense`): what they really do, when they’re worth it, and how to deploy them in production without footguns. --- ## 1) What problem does `useMemo` solve? **Answer:** `useMemo` memoizes a **computed value** so you don’t recompute it on every render. It helps when: - The calculation is **expensive** (sorting, filtering, parsing, math) - The computed object/array **identity** must remain stable to avoid child re-renders **Code: expensive derivation + stable identity** ```jsx function ProductList({ products, query }) { // Expensive filter + sort const visible = React.useMemo(() => { const q = query.trim().toLowerCase(); const filtered = products.filter(p => p.name.toLowerCase().includes(q)); // pretend this sort is expensive return filtered.sort((a, b) => a.price - b.price); }, [products, query]); // recompute only when inputs change return (

{p.name}: ${p.price}

); } ``` **Why it matters (real world):** - Large tables, analytics dashboards, editors, and charts often **recompute** heavily. - Stable arrays/objects prevent **needless re-renders** of memoized children. **Gotcha:** `useMemo` only avoids recomputation if **dependencies are stable**. If `products` is recreated each render, fix the parent first. --- ## 2) What problem does `useCallback` solve? **Answer:** `useCallback` memoizes a **function reference** so its identity stays the same across renders. It’s about **prop stability**, not speed of the function body. **Code: stabilizing handlers for memoized children** ```jsx const Row = React.memo(function Row({ onSelect, item }) { // Re-renders only when onSelect or item changes by reference return

onSelect(item.id)}>{item.name}

; }); function List({ items, onPick }) { // ❌ new function each render would force Row to re-render const handleSelect = React.useCallback( (id) => onPick(id), [onPick] // depends on onPick identity ); return

)}

; } ``` **Why it matters (real world):** - Lists of memoized rows, cells, virtualized grids: stable handler props are essential. - Prevents cascading re-renders caused by **new function identities** every render. **Gotchas:** - `useCallback` **does not** make the function faster. It just stabilizes its **reference**. - If the callback depends on changing state/props, put them in the **deps array** or use **functional updates** to avoid stale closures. --- ## 3) How do `useMemo`, `useCallback`, and `React.memo` work together? - `React.memo(Component)` skips re-render if **props are shallowly equal**. - `useCallback` helps keep **function props stable** for shallow equality. - `useMemo` keeps **object/array props stable** for shallow equality. **Code: all three in concert** ```jsx const Toolbar = React.memo(function Toolbar({ actions }) { // Only re-renders when actions identity changes return (

); }); function Editor({ onSave, onReset }) { const actions = React.useMemo( () => ({ save: onSave, reset: onReset }), [onSave, onReset] ); return ; } ``` **Anti-pattern:** Passing `{ save: onSave, reset: onReset }` inline will create a new object every render → `Toolbar` re-renders despite `React.memo`. --- ## 4) When *not* to memoize? - The computation is **cheap** and re-renders are rare. - Child components aren’t memoized, or memoization **complicates** code with no real perf win. - You haven’t **measured** a performance issue (profile first!). **Rule of thumb:** Memoize only around **hot paths** (large lists, expensive calculations, frequent renders). --- ## 5) Deps arrays without pain - Include **everything you read** inside the memo/callback (state, props, context). - If a value changes too often, **stabilize it at the source** or use **functional updates**. - Rely on **eslint-plugin-react-hooks** to catch misses. **Example: avoiding stale closure:** ```jsx function Counter() { const [count, setCount] = React.useState(0); // ✅ No stale value; uses functional update const inc = React.useCallback(() => setCount(c => c + 1), []); // ❌ Stale if you accidentally used `setCount(count + 1)` with [] return ; } ``` --- ## 6) What is `Suspense` and when should I use it? **Answer:** `Suspense` lets you **declaratively wait** for something before rendering UI, showing a **fallback** meanwhile. It coordinates **asynchronous boundaries** (code-splitting, data, images) and integrates with concurrent rendering. ### a) Code-splitting with `React.lazy` ```jsx const Chart = React.lazy(() => import("./Chart")); function Dashboard() { return ( }> {/* loaded on demand */} ); } ``` **Why it matters:** - Faster **initial loads** by splitting big components. - `fallback` provides a clean **loading state** per boundary. ### b) Suspense for data fetching (supported in frameworks / libs) Out of the box, classic client-side fetching with `useEffect` doesn’t suspend. Frameworks (e.g., Next.js with Server Components) and some libraries can integrate with Suspense to **defer UI** until data is ready. **Conceptual example: resource wrapper (learning pattern):** ```jsx // A tiny resource pattern for understanding function createResource(promise) { let status = "pending", result; const suspender = promise.then( r => { status = "success"; result = r; }, e => { status = "error"; result = e; } ); return { read() { if (status === "pending") throw suspender; // triggers Suspense fallback if (status === "error") throw result; // let ErrorBoundary handle return result; } }; } const userResource = createResource(fetch("/api/me").then(r => r.json())); function UserPanel() { const user = userResource.read(); // either returns or suspends return

Hello, {user.name}

; } function App() { return ( }> ); } ``` **Why it matters (real world):** - `Suspense` **localizes loading UI** to the boundaries that need it. - With Server Components/streaming UIs, Suspense lets you **progressively reveal** content. **Note:** For client data, many teams use **TanStack Query (React Query)** which has **experimental Suspense** support and handles caching/retries. --- ## 7) Suspense + Error Boundaries Pair Suspense with an **Error Boundary** to handle thrown errors (including rejected promises in a suspending model). ```jsx class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError() { return { hasError: true }; } render() { return this.state.hasError ?

Something went wrong.

: this.props.children; } } // Usage: }> ``` **Why it matters:** Resilient UIs: clear separation of **loading** vs **error** vs **success** UI. --- ## 8) Real-world optimization scenarios 1) **Huge filtered tables** - `useMemo` for filtered/sorted rows - `React.memo` rows + stable `rowProps` with `useMemo/useCallback` - **Virtualize** with `react-window` for big lists 2) **Canvas/Chart dashboards** - `useMemo` to precompute datasets - `useCallback` for stable event/zoom handlers passed to the chart library - `React.lazy` + `Suspense` for heavy chart components 3) **Form builders** - Split sections into memoized subforms - Stable change handlers (`useCallback`) to avoid re-render storms 4) **Design systems** - Component APIs that accept **stable objects** (`styles`, `actions`) built with `useMemo` - Memoize icons/svgs if they are complex trees used repeatedly --- ## ✅ Checklists ### Memoization Checklist - [ ] Is the computation **expensive** or the prop identity **important**? → `useMemo` - [ ] Are child components memoized and sensitive to prop identity? → `useMemo`/`useCallback` - [ ] Did you **measure** with Profiler first? ### Suspense Checklist - [ ] Wrap **lazily-loaded** components with `Suspense` - [ ] Use **localized** boundaries for better UX - [ ] Pair with **Error Boundaries** - [ ] For data: use a library/framework that supports Suspense or stick to effect-based fetching patterns --- ## TL;DR - **`useMemo`**: memoize **values** (arrays/objects/results) to cut recompute & stabilize identity. - **`useCallback`**: memoize **functions** to stabilize prop identity (works best with `React.memo`). - **`Suspense`**: declarative loading boundaries for code/data; pair with Error Boundaries; powerful with Server Components/streaming. - **Measure first.** Optimize hot paths, not everything. --- ### Up Next: Part 8: Routing, Data Loading & Error Boundaries We’ll connect performance to **real navigation**: nested routes, loaders, progressive rendering, and robust error handling patterns that make apps feel instant and resilient. --- # Part 8: Routing, Data Loading & Error Boundaries Routing ties your UI to URLs, **data loading** turns routes into screens with meaning, and **error boundaries** keep your app resilient when things go sideways. This section focuses on modern React routing patterns (React Router v6+ and framework notes for Next.js), loading data efficiently, handling mutations, and building UIs that fail gracefully. --- ## 1) What does a router do in React? **Answer:** A router keeps the UI in sync with the current URL and renders components based on a **route tree**. Modern routers also handle **nested layouts, data loading, code-splitting, and error handling**. **React Router (v6+) skeleton:** ```jsx import { createBrowserRouter, RouterProvider } from "react-router-dom"; const router = createBrowserRouter([ { path: "/", element: }, { path: "/posts", element: }, { path: "/posts/:id", element: }, ]); export default function App() { return ; } ``` **Why it matters:** Your app should be **linkable**, **shareable**, and **back/forward** friendly. Routing gives you that *and* a structure to scale. --- ## 2) Nested routes & layout routes **Answer:** Nested routes let children render within a parent layout. This avoids duplicating nav, sidebars, or breadcrumbs. ```jsx import { Outlet, NavLink } from "react-router-dom"; function DashboardLayout() { return (

); } const router = createBrowserRouter([ { path: "/dashboard", element: , children: [ { path: "overview", element: }, { path: "reports", element: }, ], }, ]); ``` **Why it matters:** Layout routes reduce duplication and make navigation **consistent** and **composable**. --- ## 3) Reading URL params and queries ```jsx import { useParams, useSearchParams, useNavigate } from "react-router-dom"; function PostDetail() { const { id } = useParams(); // /posts/:id const [search, setSearch] = useSearchParams(); // ?tab=comments const navigate = useNavigate(); const tab = search.get("tab") ?? "content"; return ( <> setSearch({ tab: t })} /> ); } ``` **Why it matters:** URLs are the single source of truth for **what** the user is viewing. Keep state in the URL when it defines the view (tab, filters, pagination), so refresh/share works. --- ## 4) Data loading (React Router loaders) Modern React Router supports **route-level data loading** (and actions for mutations). Loaders run **before** rendering the route element. ```jsx // routes.tsx import { createBrowserRouter } from "react-router-dom"; async function postsLoader() { const res = await fetch("/api/posts"); if (!res.ok) throw new Response("Failed to load posts", { status: res.status }); return res.json(); } function Posts() { const posts = useLoaderData() as Array<{ id: string; title: string }>; return

{p.title}

; } const router = createBrowserRouter([ { path: "/posts", element: , loader: postsLoader }, ]); ``` **Benefits:** - Data is **ready at render time** (less flicker). - The router can **defer**, **stream**, or **handle errors** per route boundary. - You avoid “fetch-on-mount” boilerplate and race conditions. --- ## 5) Defer, Suspense, and progressive rendering (React Router) Use `defer` to stream parts of data and show `Suspense` fallbacks while some chunks load. ```jsx import { defer, Await, useLoaderData } from "react-router-dom"; export async function productLoader({ params }) { const product = fetch(`/api/products/${params.id}`).then(r => r.json()); const reviews = fetch(`/api/products/${params.id}/reviews`).then(r => r.json()); return defer({ product, reviews }); // both promises } function ProductPage() { const data = useLoaderData() as { product: Promise; reviews: Promise }; return ( }> {product => ( <> }> {reviews => } )} ); } ``` **Why it matters:** You can render the **critical shell first** and reveal secondary data later → *perceived performance* wins. --- ## 6) Mutations with actions Route **actions** handle form submissions and other mutations. They run **before** rendering the next state and provide structured error handling. ```jsx // action for /posts/new export async function createPostAction({ request }) { const form = await request.formData(); const payload = { title: form.get("title"), body: form.get("body") }; const res = await fetch("/api/posts", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(payload), }); if (!res.ok) { return { error: "Unable to create post" }; // consumed via useActionData } return redirect("/posts"); } ``` **Form usage:** ```jsx import { Form, useActionData } from "react-router-dom"; function NewPost() { const result = useActionData() as { error?: string } | undefined; return (

<button type="submit">Create</button>
      {result?.error && <p role="alert">{result.error}</p>}
    </Form>
  );
}
```

**Why it matters:**  
Actions centralize mutations, simplify navigation after submit, and integrate with router errors.

---

## 7) Error boundaries (React Router and classic React)

**React Router per-route errors:**
```jsx
const router = createBrowserRouter([
  {
    path: "/posts/:id",
    element: <PostDetail />,
    loader: postLoader,
    errorElement: <RouteError />, // catches loader/action errors
  },
]);

function RouteError() {
  const err = useRouteError() as any;
  return (
    <div>
      <h1>Something went wrong</h1>
      <pre>{err.statusText || err.message}</pre>
      <a href="/posts">Back to Posts</a>
    </div>
  );
}
```

**Classic React Error Boundary (render-time errors):**
```jsx
class ErrorBoundary extends React.Component<{ fallback: React.ReactNode }, { hasError: boolean }> {
  state = { hasError: false };
  static getDerivedStateFromError() { return { hasError: true }; }
  componentDidCatch(error: unknown, info: unknown) {
    // send to monitoring
  }
  render() {
    return this.state.hasError ? this.props.fallback : this.props.children;
  }
}
```

**Why it matters:**  
- **Loader/action errors** → handled by `errorElement`.
- **Render-time errors** → handled by Error Boundaries.
- Combine both for robust UX.

---

## 8) Code-splitting routes

```jsx
const Posts = React.lazy(() => import("./routes/Posts"));
const PostDetail = React.lazy(() => import("./routes/PostDetail"));

const router = createBrowserRouter([
  {
    path: "/posts",
    element: (
      <React.Suspense fallback={<Spinner />}>
        <Posts />
      </React.Suspense>
    ),
  },
  {
    path: "/posts/:id",
    element: (
      <React.Suspense fallback={<Spinner />}>
        <PostDetail />
      </React.Suspense>
    ),
  },
]);
```

**Why it matters:**  
You only ship the code needed for the current screen → **faster initial loads**.

---

## 9) Next.js (App Router) Notes: Server Components & data

If you’re using Next.js (App Router):
- Routes live in `app/` with **nested layouts** (`layout.tsx`) and **server components** by default.
- Data fetching is often done **on the server** (`async` server components) with automatic streaming & Suspense.
- Errors handled via `error.tsx` and `not-found.tsx`.
- Client components (`"use client"`) can still use client hooks.

**Example (Next.js server component):**
```tsx
// app/posts/[id]/page.tsx
import { notFound } from "next/navigation";

export default async function PostPage({ params }: { params: { id: string } }) {
  const res = await fetch(`${process.env.API}/posts/${params.id}`, { cache: "no-store" });
  if (!res.ok) notFound();
  const post = await res.json();
  return <article><h1>{post.title}</h1><p>{post.body}</p></article>;
}
```

**Why it matters:**  
Server Components reduce client bundle size, enable **streaming**, and pair naturally with Suspense boundaries.

---

## 10) User experience patterns

- **Skeletons > spinners** for perceived speed, especially below-the-fold content.  
- **Prefetch on hover** (React Router `link rel=prefetch` or Next `prefetch`) for snappy nav.  
- Keep **state in the URL** when it defines the view (filters, page, tab).  
- Use **optimistic UI** for mutations (update UI first, rollback on failure).  
- Provide **retry** actions on error screens.

---

## 11) Accessibility with routing

- Update the **document title** per route (Router can assist; frameworks do it automatically).  
- Manage **focus** on navigation (focus heading or main region).  
- Use **Skip to content** links; landmark roles (`<main>`, `<nav>`) help screen readers.  
- Route errors should announce with `role="alert"`.

**Focus example after navigation:**
```jsx
function Screen({ title, children }) {
  const ref = React.useRef<HTMLHeadingElement>(null);
  React.useEffect(() => { ref.current?.focus(); }, [title]);
  return (
    <>
      <h1 tabIndex={-1} ref={ref}>{title}</h1>
      <div>{children}</div>
    </>
  );
}
```

---

## 12) Handling race conditions & cancellation (client fetch)

If you still fetch in components, cancel in `useEffect`:

```jsx
function Post({ id }) {
  const [post, setPost] = React.useState(null);
  React.useEffect(() => {
    const ctl = new AbortController();
    fetch(`/api/posts/${id}`, { signal: ctl.signal })
      .then(r => r.json())
      .then(setPost)
      .catch(e => { if (e.name !== "AbortError") throw e; });
    return () => ctl.abort();
  }, [id]);
  // ...
}
```

With **route loaders**, the router handles a lot of this for you.

---

## ✅ Checklists

### Routing
- [ ] Use **nested routes** for shared layouts  
- [ ] Keep **view-defining state** in the URL (params/search)  
- [ ] Use **stable keys** for lists so back/forward behaves well  
- [ ] Prefer **link navigation** over imperative `navigate` when possible

### Data Loading
- [ ] Prefer **route loaders** (or server components in frameworks)  
- [ ] Use **defer + Suspense** for progressive rendering  
- [ ] Centralize **mutations** with actions (or framework handlers)  
- [ ] Handle **errors** close to the route with `errorElement`

### Resilience
- [ ] Pair **Suspense** with **Error Boundaries**  
- [ ] Provide **retry** and **contact support** paths  
- [ ] Log errors to monitoring (Sentry, Datadog, etc.)

### UX & Perf
- [ ] Use **skeletons** for perceived speed  
- [ ] **Prefetch** links for common next routes  
- [ ] **Code-split** route components  
- [ ] Manage **focus** and **title** changes for a11y

---

## TL;DR

- Routes describe **where** you are; loaders/actions describe **what data** you need and **what changes** you make.
- **Nested layouts** keep structure DRY; **defer + Suspense** deliver progressive UIs.
- **Error boundaries** and route `errorElement`s isolate failures so the app stays usable.
- Frameworks like **Next.js** push more work to the server with Server Components and built-in conventions. Embrace them where they fit.

---

### Up Next: Part 9: Testing & Accessibility for Real Apps
We’ll cover **Testing Library** patterns, mocking fetch, end-to-end flows, and accessibility checks that catch issues *before* your users do.

---

# Part 9: Testing & Accessibility for Real Apps

Testing ensures your React apps behave correctly under change. Accessibility (a11y) ensures your apps are usable by everyone. Both are essential to **quality**, **confidence**, and **longevity**. This section covers **unit & integration testing** with React Testing Library (RTL), end-to-end testing with tools like Playwright/Cypress, and practical accessibility practices & checks.

---

## 1) Why test React apps?

**Answer:**  
- **Confidence**: Refactoring without fear.  
- **Regression safety**: Prevents old bugs from reappearing.  
- **Documentation**: Tests describe how the app *should* behave.  
- **Accessibility**: Automated tests can catch common a11y mistakes.

**Rule of thumb:**  
> Test behavior, not implementation details.  
That means test *what the user sees and does*, not *which hook you used*.

---

## 2) Tools overview

- **Jest** → Test runner (ships with most React setups).  
- **React Testing Library (RTL)** → DOM testing focused on user perspective.  
- **Playwright / Cypress** → End-to-end browser automation.  
- **axe-core / jest-axe** → Accessibility assertions.  
- **Vitest** → Fast alternative to Jest (works with Vite).

---

## 3) Unit & integration tests with RTL

**Component test:**
```jsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import Counter from "./Counter";

test("increments counter when button clicked", async () => {
  render(<Counter />);
  await userEvent.click(screen.getByRole("button", { name: /increment/i }));
  expect(screen.getByText(/count: 1/i)).toBeInTheDocument();
});
```

**Principles:**
- Query elements by **role**, **label text**, **placeholder**, **alt text**, etc.  
- Avoid `getByTestId` unless no semantic alternative.  
- Use `userEvent` instead of `fireEvent` for realistic interactions.

---

## 4) Mocking APIs in tests

**RTL + MSW (Mock Service Worker):**
```jsx
import { rest } from "msw";
import { setupServer } from "msw/node";
import { render, screen } from "@testing-library/react";
import App from "./App";

const server = setupServer(
  rest.get("/api/posts", (req, res, ctx) => res(ctx.json([{ id: 1, title: "Hello" }])))
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test("renders posts", async () => {
  render(<App />);
  expect(await screen.findByText(/hello/i)).toBeInTheDocument();
});
```

**Why MSW?**  
- Mocks **real network layer** (fetch/XHR).  
- Works in **tests and dev** (offline development).  
- More reliable than patching `global.fetch`.

---

## 5) Integration testing flows

**Test a login flow:**
```jsx
test("logs in with correct credentials", async () => {
  render(<Login />);
  await userEvent.type(screen.getByLabelText(/email/i), "test@example.com");
  await userEvent.type(screen.getByLabelText(/password/i), "secret123");
  await userEvent.click(screen.getByRole("button", { name: /log in/i }));
  expect(await screen.findByText(/welcome/i)).toBeInTheDocument();
});
```

> Focus on **user perspective** (labels, buttons, visible text). This ensures you test **a11y & UX** as well as logic.

---

## 6) Snapshot tests: When (and When Not) to Use

- ✅ Great for **pure UI components** (icons, static markup).  
- ❌ Fragile for **dynamic UIs** (snapshots get too large, unhelpful diffs).

**Better:** prefer **explicit assertions** over giant snapshots.

---

## 7) End-to-end (E2E) testing

Use Playwright or Cypress for **real browser flows**:
- Navigation between pages  
- Full login/signup/logout  
- API + UI integration  
- Mobile viewport simulation

**Playwright example:**
```ts
import { test, expect } from "@playwright/test";

test("user can create a new post", async ({ page }) => {
  await page.goto("/posts/new");
  await page.fill('input[name="title"]', "My Post");
  await page.fill('textarea[name="body"]', "Content goes here");
  await page.click("text=Create");
  await expect(page).toHaveURL(/posts/);
  await expect(page.locator("h1")).toContainText("My Post");
});
```

**Best practices:**
- Keep E2E tests **few but critical** (happy paths, critical flows).  
- Don’t replace unit/integration with E2E → they’re **slower** and **flakier**.

---

## 8) Accessibility (a11y) testing

### Automated checks
Use `jest-axe` with RTL:
```jsx
import { render } from "@testing-library/react";
import { axe } from "jest-axe";
import Login from "./Login";

test("login form is accessible", async () => {
  const { container } = render(<Login />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});
```

### Manual essentials
- Use keyboard: Can you tab through and activate everything?  
- Screen reader check: Are buttons/inputs labeled? Headings structured?  
- Color contrast check (WCAG AA at least).

### Common mistakes
- Missing `alt` text on images.  
- Buttons/links without labels.  
- Using `div` instead of semantic HTML (`button`, `nav`, `main`).  
- Insufficient focus states.

---

## 9) Testing accessibility interactions

Example: **focus management after modal opens**
```jsx
test("focus moves to modal when opened", async () => {
  render(<ModalExample />);
  await userEvent.click(screen.getByRole("button", { name: /open modal/i }));
  expect(screen.getByRole("dialog")).toHaveFocus();
});
```

---

## 10) Continuous integration (CI) & coverage

- Run tests on every PR (GitHub Actions, GitLab CI, etc).  
- Collect coverage (`--coverage`) but don’t chase 100% → focus on **critical paths**.  
- Run **fast unit tests** on every push, **E2E** nightly or on release branch.

---

## ✅ Checklists

### Testing
- [ ] Write tests from the **user’s perspective** (roles, labels, text).  
- [ ] Use **RTL + MSW** for integration-level reliability.  
- [ ] Prefer **explicit assertions** over brittle snapshots.  
- [ ] Keep **E2E tests minimal** but cover critical flows.

### Accessibility
- [ ] Provide **labels** for all inputs, buttons, links.  
- [ ] Ensure **focus management** on navigation & dialogs.  
- [ ] Check **color contrast** and visible focus outlines.  
- [ ] Test with **keyboard-only** navigation.  
- [ ] Add **automated a11y checks** (jest-axe, axe-playwright).

---

## TL;DR

- **Test behaviors, not implementation details.**  
- Use **unit + integration** tests for most cases, **E2E** only for critical flows.  
- Accessibility is not optional: combine **automated checks** with **manual testing**.  
- Aim for **confidence, not coverage**.  
- Bake tests into CI to keep regressions out.

---

### Up Next: Part 10: Performance Optimization & Advanced Patterns
We’ll cover **profiling React apps**, **memoization**, **virtualization**, and **concurrent rendering patterns** to keep apps snappy even at scale.

---

# Part 10: Performance Optimization & Advanced Patterns

Performance isn’t just about sprinkling `useMemo` everywhere. It’s a **discipline**: measure, pinpoint, fix the *right* thing, and keep it fast as features grow. This part gives you a practical playbook: from profiling to concurrency, virtualization, caching, and off-main-thread work.

---

## 1) How do I profile React apps *properly*?

**Answer:**  
Start with **evidence**, not hunches.

1) **React DevTools Profiler**  
   - Record a user flow (e.g., typing or opening a panel).  
   - Identify the **slowest commits** and **hot components**.  
   - Expand why a component re-rendered (props/state/context changed).

2) **Browser Performance panel**  
   - Look for **long tasks** (>50ms), layout thrash, and script eval time.

3) **Field metrics**  
   - Track Core Web Vitals (FID/INP, LCP, CLS) in production.

**Why it matters:**  
You only have time to fix a few things. Make sure they’re the ones that move the needle.

---

## 2) Co-locate state and split components to reduce churn

**Answer:**  
Re-renders bubble down. If a parent’s state changes, all children *run* again. Mitigate by:

- **Co-locating state** near the component that truly owns it.  
- **Splitting components** so unaffected subtrees don’t re-render.  
- Memoize leaf components when useful.

**Code: split + memoize**
```jsx
const Summary = React.memo(function Summary({ total }) {
  return <div>Total: {total}</div>;
});

function Cart({ items }) {
  const total = React.useMemo(
    () => items.reduce((s, it) => s + it.price * it.qty, 0),
    [items]
  );
  return (
    <>
      <ItemList items={items} />   {/* re-renders when items change */}
      <Summary total={total} />    {/* isolated from ItemList internals */}
    </>
  );
}
```

**Why it matters:**  
Smaller render surfaces = fewer wasted renders.

---

## 3) Virtualize large lists

Rendering 10k rows kills frame rate. **Window** them.

```jsx
import { FixedSizeList as List } from "react-window";

function BigList({ rows }) {
  return (
    <List height={500} itemCount={rows.length} itemSize={40} width={600}>
      {({ index, style }) => (
        <div style={style}>{rows[index].label}</div>
      )}
    </List>
  );
}
```

- Use `VariableSizeList` for uneven row heights.  
- Memoize row renderers if they receive stable props.

**Why it matters:**  
Virtualization is often the **single biggest win** for UI that shows lots of data.

---

## 4) Concurrency tools: `startTransition` and `useDeferredValue`

React 18 lets you **prioritize urgent updates** (like typing) over expensive ones (like filtering).

### a) `startTransition`: Mark non-urgent updates
```jsx
import { startTransition } from "react";

function Search({ list }) {
  const [query, setQuery] = React.useState("");
  const [filtered, setFiltered] = React.useState(list);

function handleChange(e) {
    const q = e.target.value;
    setQuery(q); // urgent: keep typing snappy
    startTransition(() => { // non-urgent: can be interrupted
      setFiltered(list.filter(x => x.includes(q)));
    });
  }

return (
    <>
      <input value={query} onChange={handleChange} />
      <Results items={filtered} />
    </>
  );
}
```

### b) `useDeferredValue`: Let React reuse stale value briefly
```jsx
function SearchResults({ query, list }) {
  const deferredQuery = React.useDeferredValue(query);
  const results = React.useMemo(
    () => list.filter(x => x.includes(deferredQuery)),
    [list, deferredQuery]
  );
  return <Results items={results} />;
}
```

**Why it matters:**  
Keeps input responsive even under heavy list filtering or rendering.

---

## 5) Code-splitting with `React.lazy` and localized Suspense

Split heavy components (charts, editors) to speed up initial load.

```jsx
const Chart = React.lazy(() => import("./Chart"));

function Dashboard() {
  return (
    <React.Suspense fallback={<ChartSkeleton />}>
      <Chart />
    </React.Suspense>
  );
}
```

**Tips:**  
- Put **small Suspense boundaries** around heavy widgets, not the whole app.  
- Prefetch on hover if your router/framework supports it.

---

## 6) Caching & server state: React Query (TanStack Query) pattern

Not all “state” belongs in React. **Server state** benefits from caching, deduping, retries.

```jsx
import { useQuery } from "@tanstack/react-query";

function Users() {
  const { data, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(r => r.json()),
    staleTime: 60_000, // 1 minute: avoid refetching on every focus
    select: rows => rows.slice(0, 50) // derive once, memoized by cache
  });

if (isLoading) return <Spinner />;
  if (error) return <ErrorBox />;

return <UserTable rows={data} />;
}
```

**Why it matters:**  
Avoids re-fetch storms, normalizes async flows, and simplifies retries and background updates.

---

## 7) Avoid “giant contexts” and re-render storms

**Problem:** One huge context value makes **the whole tree** re-render on any change.

**Solutions:**  
- Split contexts by concern (theme vs auth vs preferences).  
- Use **selector** contexts (expose primitive values separately).  
- Memoize provider values (`useMemo`) to keep reference stable.

```jsx
const AuthContext = React.createContext({ user: null, signOut: () => {} });

---

## 8) Image & asset performance

- Use responsive images: `srcset`, `sizes`.  
- Lazy load below-the-fold images: `<img loading="lazy" decoding="async" />`.  
- Preload critical fonts/styles.  
- Prefer CSS transforms (GPU-friendly) over layout-changing properties.

```html
<img
  src="/img/600.jpg"
  srcset="/img/600.jpg 600w, /img/1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="Product"
  loading="lazy"
  decoding="async"
/>
```

---

## 9) Off-main-thread work with Web Workers

If you have heavy, synchronous computations, move them off the UI thread.

**With Comlink (nice ergonomics):**
```js
// worker.js
import * as Comlink from "comlink";
const api = {
  heavyCalc(n) { /* ...expensive... */ return n; }
};
Comlink.expose(api);
```

```jsx
// main thread
import * as Comlink from "comlink";

const worker = new Worker(new URL("./worker.js", import.meta.url), { type: "module" });
const api = Comlink.wrap(worker);

async function run() {
  const result = await api.heavyCalc(1_000_000);
  console.log(result);
}
```

**Why it matters:**  
Keeps the main thread free for **input and paint**, preventing jank.

---

## 10) Debounce, throttle, and `requestAnimationFrame`

- **Debounce** keystrokes before calling APIs.  
- **Throttle** scroll/resize handlers.  
- Use `requestAnimationFrame` for visual updates tied to frames.

```js
function debounce(fn, ms = 200) {
  let t; return (...args) => { clearTimeout(t); t = setTimeout(() => fn(...args), ms); };
}
```

```jsx
// example: debounced search input
const onChange = React.useMemo(() => debounce((q) => search(q), 300), [search]);
```

---

## 11) Batching & state updates

React 18 batches updates in **more cases** (including async events). Prefer **functional updates** to avoid stale state and unnecessary re-renders.

```jsx
setCount(c => c + 1);
setTotal(t => t + delta);
```

---

## ✅ Checklists

### Profiling & Strategy
- [ ] Use **React Profiler** to find real bottlenecks  
- [ ] Record **specific user flows** (typing, filtering, route change)  
- [ ] Prioritize fixes by **time spent** and **frequency**

### Rendering
- [ ] Co-locate state; split large components  
- [ ] Memoize leaf components and heavy computations  
- [ ] Stabilize function/object identities (`useCallback`/`useMemo`)

### Data & Lists
- [ ] Virtualize long lists (`react-window`)  
- [ ] Cache server data (React Query) with sensible `staleTime`  
- [ ] Avoid giant contexts; split or add selectors

### Concurrency & UX
- [ ] Use `startTransition` for non-urgent updates  
- [ ] Use `useDeferredValue` for responsive typing + heavy filtering  
- [ ] Localize Suspense boundaries and code-split heavy widgets

### Assets & Threads
- [ ] Lazy load non-critical images; use responsive images  
- [ ] Push expensive work to a **Web Worker**  
- [ ] Debounce/throttle high-frequency events

---

## TL;DR

- **Measure first**, then optimize the hot path.  
- Reduce re-render surface with **state colocation**, **component splits**, and **memoization**.  
- Speed up perceived performance with **Suspense**, **code-splitting**, and **progressive rendering**.  
- Keep the main thread free: **virtualize lists**, **cache data**, **use workers** for heavy work.  
- Performance is a **process**, not a single trick.

---

### Up Next: Part 11: Patterns for Reusability (Compound Components, Headless UI, and Design Systems)
We’ll focus on building **reusable, accessible components** and **headless patterns** that scale across apps and teams without sacrificing flexibility.

---

# Part 11: Patterns for Reusability: Compound Components, Headless UI & Design Systems

Reusable components aren’t just “buttons you can import.” They’re **APIs for UI**: composable, accessible, and adaptable across contexts. In this part we’ll build patterns used by real design systems: **Compound Components**, **Headless Components**, and **API design principles** that keep teams moving fast without locking them in.

---

## 1) What makes a component *reusable*?

**Answer (principles):**
- **Single responsibility**: One job (e.g., Tabs orchestrates tab state, TabList/Tab/TabPanels render).
- **Composition over configuration**: Prefer JSX composition to a giant prop bag.
- **Controlled *and* uncontrolled**: Support internal state by default *and* allow callers to control it.
- **Accessible by default**: ARIA roles, keyboard interactions, focus management.
- **Escape hatches**: ClassName/style slots, render props, as-child APIs for advanced use.

---

## 2) Compound Components (Tabs example)

Compound components share implicit state via React context so consumers can compose subcomponents freely.

### Implementation (headlines only, full example below)
- `Tabs` (provider): owns active index; controls keyboard and selection
- `TabList`, `Tab`, `TabPanels`, `TabPanel`: read/write context

```jsx
// Tabs.tsx
const TabsContext = React.createContext(null);

function Tabs({ defaultIndex = 0, value, onChange, children }) {
  const [index, setIndex] = React.useState(defaultIndex);
  const isControlled = value != null;
  const active = isControlled ? value : index;

const select = React.useCallback(
    (i) => {
      if (!isControlled) setIndex(i);
      onChange?.(i);
    },
    [isControlled, onChange]
  );

const ctx = React.useMemo(() => ({ active, select }), [active, select]);

return (
    <TabsContext.Provider value={ctx}>
      <div role="tablist" aria-orientation="horizontal">
        {children}
      </div>
    </TabsContext.Provider>
  );
}

function TabPanels({ children }) {
  const ctx = React.useContext(TabsContext);
  return React.Children.map(children, (child, i) =>
    React.cloneElement(child, { index: i, active: ctx.active === i })
  );
}

function TabPanel({ children, index, active }) {
  return (
    <div
      role="tabpanel"
      id={`panel-${index}`}
      aria-labelledby={`tab-${index}`}
      hidden={!active}
    >
      {children}
    </div>
  );
}

// Usage
<Tabs defaultIndex={0}>
  <div className="tab-list">
    <Tab index={0}>General</Tab>
    <Tab index={1}>Billing</Tab>
    <Tab index={2}>Security</Tab>
  </div>
  <TabPanels>
    <TabPanel>General Settings</TabPanel>
    <TabPanel>Billing Info</TabPanel>
    <TabPanel>Security Options</TabPanel>
  </TabPanels>
</Tabs>
```

**Why it matters:**  
- Consumers compose `Tab`, `TabPanels`, `TabPanel` however they want (place them in different layouts).
- Accessible roles are built-in.
- Easy to **control** from outside by passing `value` and `onChange`.

**Level-up:** Add keyboard support (ArrowLeft/Right), roving tabindex, and announce changes for screen readers.

---

## 3) Headless Components (Unstyled but fully accessible)

**Headless** means you ship **logic + accessibility**, but **no styles**. Consumers bring their own UI. Think Radix UI, Headless UI.

### Example: Headless `useDisclosure` hook + `Disclosure` components
```jsx
function useDisclosure({ defaultOpen = false, open, onOpenChange } = {}) {
  const [internal, setInternal] = React.useState(defaultOpen);
  const isControlled = open != null;
  const isOpen = isControlled ? open : internal;

const setOpen = React.useCallback(
    (v) => {
      const next = typeof v === "function" ? v(isOpen) : v;
      if (!isControlled) setInternal(next);
      onOpenChange?.(next);
    },
    [isControlled, isOpen, onOpenChange]
  );

return { isOpen, setOpen, toggle: () => setOpen(o => !o) };
}

const DisclosureContext = React.createContext(null);

function Disclosure(props) {
  const api = useDisclosure(props);
  return (
    <DisclosureContext.Provider value={api}>
      {props.children}
    </DisclosureContext.Provider>
  );
}

function DisclosureButton({ as: Comp = "button", children, ...rest }) {
  const { isOpen, toggle } = React.useContext(DisclosureContext);
  return (
    <Comp
      aria-expanded={isOpen}
      aria-controls="disclosure-panel"
      onClick={toggle}
      {...rest}
    >
      {children}
    </Comp>
  );
}

function DisclosurePanel({ as: Comp = "div", children, ...rest }) {
  const { isOpen } = React.useContext(DisclosureContext);
  return (
    <Comp id="disclosure-panel" hidden={!isOpen} {...rest}>
      {children}
    </Comp>
  );
}

// Usage: style it however you want
<Disclosure defaultOpen={false}>
  <DisclosureButton className="btn btn-ghost">Details</DisclosureButton>
  <DisclosurePanel className="p-4 border rounded">
    Here is some extra information…
  </DisclosurePanel>
</Disclosure>
```

**Why it matters:**  
- Your **design system stays unopinionated** about CSS frameworks or brand themes.
- Teams can adopt logic + accessibility instantly and layer any UI library.

---

## 4) Controlled vs Uncontrolled APIs (for reusability)

A reusable component should often support **both** patterns:

- **Uncontrolled** (simple): manages its own state internally.
- **Controlled** (advanced): state driven by parent via props.

**Pattern: `value` + `defaultValue` + `onChange`**
```jsx
function Slider({ value, defaultValue = 0, onChange }) {
  const [internal, setInternal] = React.useState(defaultValue);
  const isControlled = value != null;
  const current = isControlled ? value : internal;

const set = (v) => {
    if (!isControlled) setInternal(v);
    onChange?.(v);
  };

return (
    <input
      type="range"
      value={current}
      onChange={(e) => set(Number(e.target.value))}
      aria-valuenow={current}
    />
  );
}
```

**Why it matters:**  
- **Uncontrolled** is drop-in easy.
- **Controlled** enables form libraries, external state, and predictable testing.

---

## 5) API Surface: Props, Slots & Render Props

- **Slots**: pass JSX to “areas” of your component (e.g., `header`, `footer`).
- **Render props**: pass a function child to access internal state/actions.
- **As-child** pattern: let consumers swap the rendered element (use `as` prop).

**Render-prop example:**
```jsx
function Toggle({ children }) {
  const [on, setOn] = React.useState(false);
  const api = { on, toggle: () => setOn(o => !o) };
  return children(api);
}

<Toggle>
  {({ on, toggle }) => (
    <button aria-pressed={on} onClick={toggle}>
      {on ? "On" : "Off"}
    </button>
  )}
</Toggle>
```

**Why it matters:**  
These patterns make components **extensible without forking**.

---

## 6) Accessibility baked in

- Use **semantic roles** (`role="tab"`, `role="tabpanel"`, `role="dialog"`, etc.).
- Keep **focus management** correct (focus the active tab, trap focus in dialogs).
- Support **keyboard** (arrows to move, Enter/Space to activate).
- Announce state changes with ARIA where applicable (`aria-expanded`, `aria-live`).

**Keyboard support for Tabs (sketch):**
```jsx
function TabList({ children }) {
  const listRef = React.useRef(null);
  const { active, select } = React.useContext(TabsContext);

function onKeyDown(e) {
    const tabs = Array.from(listRef.current.querySelectorAll('[role="tab"]'));
    const current = tabs.findIndex(el => el.id === `tab-${active}`);
    if (e.key === "ArrowRight") select((current + 1) % tabs.length);
    if (e.key === "ArrowLeft") select((current - 1 + tabs.length) % tabs.length);
  }

return (
    <div ref={listRef} role="tablist" onKeyDown={onKeyDown}>
      {children}
    </div>
  );
}
```

---

## 7) Testing reusable components

- **Unit**: role-based queries (RTL) to ensure semantics & interactions.
- **Accessibility**: `jest-axe` to catch ARIA issues early.
- **Contract tests**: verify controlled/uncontrolled behavior and event payloads.

```jsx
test("Tabs selects the right panel on click", async () => {
  render(
    <Tabs defaultIndex={0}>
      <div>
        <Tab index={0}>A</Tab>
        <Tab index={1}>B</Tab>
      </div>
      <TabPanels>
        <TabPanel>Panel A</TabPanel>
        <TabPanel>Panel B</TabPanel>
      </TabPanels>
    </Tabs>
  );
  await userEvent.click(screen.getByRole("tab", { name: "B" }));
  expect(screen.getByRole("tabpanel")).toHaveTextContent("Panel B");
});
```

---

## 8) Styling strategies for design systems

- **Headless + CSS-in-Your-Stack** (Tailwind, CSS Modules, Vanilla Extract).
- **Class slots**: `classNames={{ root, tab, panel }}` or `slotProps`.
- **As-child** renders**:** component delegates element rendering to consumer for full control.

**Slots example:**
```jsx
function Card({ title, children, slots = {} }) {
  const { Root = "div", Header = "div", Body = "div" } = slots;
  return (
    <Root className="card">
      <Header className="card-header">{title}</Header>
      <Body className="card-body">{children}</Body>
    </Root>
  );
}

// Usage: swap Body with a section
<Card title="Hello" slots={{ Body: "section" }}>
  Content here
</Card>
```

---

## 9) When to create a design system (and when not)

**Create one when:**
- Multiple apps/teams need **shared UI**.
- You’ll maintain components long-term (docs, accessibility, theming).
- You can dedicate time to **APIs + a11y** + **testing**.

**Avoid or delay when:**
- You’re pre-MVP or UI requirements are volatile.
- Team lacks bandwidth to maintain it (stale DS slows everyone down).

**Middle path:** Start with **headless primitives** that wrap accessibility & logic, style per app.

---

## 10) Checklist for reusable component APIs

- [ ] Supports **uncontrolled** defaults + **controlled** mode (`value`, `onChange`)  
- [ ] **Accessible by default** (roles, aria-*, keyboard, focus)  
- [ ] **Composable** (compound pieces + context)  
- [ ] Escape hatches: `className`, `style`, `as`, **render props** or **slots**  
- [ ] Stable identities for memoized children (avoid prop churn)  
- [ ] Tested (RTL + jest-axe)  
- [ ] Documented with code examples and dos/don’ts

---

## TL;DR

- **Compound components** enable flexible, declarative APIs driven by shared context.  
- **Headless components** deliver logic + a11y while letting teams style however they want.  
- Support **controlled/uncontrolled** patterns for broad applicability.  
- Build **accessibility in** from the start.  
- Provide **escape hatches** so consumers can extend without forking.  
- Test like a user; document like a system.

---

### Up Next: Part 12: Data Fetching, Mutations & Caching (Practical)
We’ll combine what you’ve learned to build robust flows with **React Query**, mutation lifecycles, optimistic updates, infinite queries, and strategies to keep UIs fresh without over-fetching.

---

# Part 12: Data Fetching, Mutations & Caching in React

Fetching and mutating data is at the heart of every React application. How you design your data layer determines not only **performance** but also **user experience**. In modern React, libraries like **React Query (TanStack Query)**, **SWR**, and **Apollo Client** give us robust caching, automatic revalidation, and easy mutation flows. Let’s break down the concepts and practices you’ll see in production apps.

---

## 1) Why not just `useEffect + fetch`?

Naive data fetching with `useEffect` looks like this:

```jsx
const [data, setData] = React.useState(null);
const [loading, setLoading] = React.useState(true);

useEffect(() => {
  fetch("/api/todos")
    .then(res => res.json())
    .then(setData)
    .finally(() => setLoading(false));
}, []);
```

**Problems:**
- No caching → Every mount re-fetches data.
- No background updates → Stale data lingers.
- No retry or error handling → Manual plumbing needed.
- No support for mutations → You have to refetch after a write.

This is where data libraries shine.

---

## 2) React Query / TanStack Query Overview

**React Query (a.k.a. TanStack Query)** solves common data fetching issues:

- Query caching and deduplication  
- Stale-while-revalidate semantics  
- Automatic retries + exponential backoff  
- Background refreshes  
- Mutations with optimistic updates and rollbacks  
- Pagination & infinite scroll

```bash
npm install @tanstack/react-query
```

**Setup:**
```jsx
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

const queryClient = new QueryClient();

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Todos />
    </QueryClientProvider>
  );
}
```

---

## 3) Queries (Fetching Data)

```jsx
import { useQuery } from "@tanstack/react-query";

function Todos() {
  const { data, isLoading, error } = useQuery({
    queryKey: ["todos"],
    queryFn: () => fetch("/api/todos").then(res => res.json())
  });

if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Something went wrong</p>;

return (
    <ul>
      {data.map(todo => <li key={todo.id}>{todo.text}</li>)}
    </ul>
  );
}
```

### Key Concepts
- **queryKey**: Unique cache identifier (`["todos"]`).
- **queryFn**: Function that fetches data.
- **Caching**: Data persists across components, tabs, and navigations.
- **Refetching**: Happens on window focus or interval by default.

---

## 4) Mutations (Writing Data)

Mutations handle **POST/PUT/DELETE** actions.

```jsx
import { useMutation, useQueryClient } from "@tanstack/react-query";

function AddTodo() {
  const queryClient = useQueryClient();

const mutation = useMutation({
    mutationFn: (newTodo) =>
      fetch("/api/todos", {
        method: "POST",
        body: JSON.stringify(newTodo)
      }).then(res => res.json()),

onSuccess: () => {
      // Invalidate cache so Todos refetch
      queryClient.invalidateQueries(["todos"]);
    }
  });

return (
    <button
      onClick={() => mutation.mutate({ text: "Buy milk" })}
      disabled={mutation.isPending}
    >
      Add Todo
    </button>
  );
}
```

---

## 5) Optimistic Updates

Make UIs feel instant by updating the cache before the server confirms.

```jsx
const mutation = useMutation({
  mutationFn: updateTodo,
  onMutate: async (updated) => {
    await queryClient.cancelQueries(["todos"]);

**Real-world example:** Updating a like count in a social feed instantly while the network request resolves.

---

## 6) Infinite Queries & Pagination

For feeds, search results, or scrolling UIs:

```jsx
const {
  data,
  fetchNextPage,
  hasNextPage,
  isFetchingNextPage
} = useInfiniteQuery({
  queryKey: ["messages"],
  queryFn: ({ pageParam = 0 }) =>
    fetch(`/api/messages?cursor=${pageParam}`).then(r => r.json()),
  getNextPageParam: (lastPage) => lastPage.nextCursor,
});
```

- Data returned as **pages** you can flatten (`data.pages.flatMap(p => p.items)`).
- Automatic "load more" buttons or infinite scroll.

---

## 7) Background Updates & Revalidation

React Query implements **Stale-While-Revalidate**:
- Shows cached data instantly.
- Fetches fresh data in the background.
- Updates UI when new data arrives.

Useful for:
- Dashboards that always need the latest numbers.
- Feeds that refresh on window focus.

```jsx
useQuery({
  queryKey: ["stats"],
  queryFn: fetchStats,
  staleTime: 60_000,   // Data fresh for 1 min
  refetchOnWindowFocus: true
});
```

---

## 8) Error Handling & Retries

```jsx
useQuery({
  queryKey: ["users"],
  queryFn: fetchUsers,
  retry: 3, // Retry 3 times
  retryDelay: attempt => Math.min(1000 * 2 ** attempt, 30_000)
});
```

- **Retry strategy** for flaky networks.
- **Error boundaries** + `useErrorBoundary` to bubble errors up.

---

## 9) When to use SWR vs React Query

- **React Query**: Full-featured, handles mutations, infinite queries, complex apps.
- **SWR**: Simpler API, focused on GET requests + revalidation (great for Next.js apps).

Example with SWR:
```jsx
import useSWR from "swr";

function Profile() {
  const { data, error, isLoading } = useSWR("/api/user", url =>
    fetch(url).then(r => r.json())
  );
}
```

---

## 10) Testing Data Fetching

- **Mock Service Worker (MSW)**: intercept fetch in tests.
- **Contract tests**: verify caching, retries, optimistic updates.
- **End-to-end**: ensure optimistic updates + rollback work against the real backend.

---

## ✅ 11) Best Practices

- **Use query keys consistently** (`["todos", userId]` vs `["todos"]`).
- **Invalidate narrowly** (don’t invalidate all queries if you can target one).
- **Co-locate queries** with components that use them.
- **Prefetch** data for navigation to avoid skeleton screens.
- **Persist cache** across reloads (React Query provides `persistQueryClient`).

---

## 12) What’s next?

React Query + Suspense integration is improving:
- Direct `use` of async queries.
- Streaming server data with React Server Components.
- Zero-configuration loading states in concurrent React.

---

## TL;DR

- **Don’t roll your own data cache.** Use React Query or SWR.
- Queries = fetch + cache, Mutations = writes + invalidation.
- Optimistic updates make UIs snappy.
- Infinite queries power scrolling feeds.
- Revalidation keeps UIs fresh with little effort.
- Handle errors + retries gracefully.
- Build with caching in mind. It’s not just an optimization, it’s part of the UX.

---

### Up Next: Part 13: Forms in React (Controlled, Uncontrolled, and Form Libraries)
We’ll explore controlled inputs, uncontrolled refs, form validation, libraries like React Hook Form & Formik, and real-world patterns for large-scale forms.

---

# Part 13: Forms in React: Controlled, Uncontrolled, and Beyond

Forms are the **bread and butter of interactivity** on the web. Whether it’s a login form, checkout page, or a complex dashboard input, React developers need to understand the fundamentals of form handling. Before diving into libraries, it’s critical to master **controlled vs. uncontrolled inputs**, the foundation for everything else.

---

## 1) Controlled Components

A **controlled component** is a form input whose **value is driven by React state**. Every keystroke updates state, and the component re-renders with the latest value.

```jsx
function ControlledForm() {
  const [name, setName] = React.useState("");

const handleSubmit = (e) => {
    e.preventDefault();
    alert(`Submitted: ${name}`);
  };

return (
    <form onSubmit={handleSubmit}>
      <input
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
      <button type="submit">Submit</button>
    </form>
  );
}
```

**Why it matters:**
- React has **full control** of the input value.
- Easy to validate and manipulate user input.
- Great for small/medium forms where you need tight synchronization.

⚠️ Downside: Large forms with many controlled inputs can cause excessive re-renders and performance bottlenecks.

---

## 2) Uncontrolled Components

An **uncontrolled component** lets the **DOM manage the input value**. React only references the value when needed using a `ref`.

```jsx
function UncontrolledForm() {
  const inputRef = React.useRef();

const handleSubmit = (e) => {
    e.preventDefault();
    alert(`Submitted: ${inputRef.current.value}`);
  };

return (
    <form onSubmit={handleSubmit}>
      <input ref={inputRef} />
      <button type="submit">Submit</button>
    </form>
  );
}
```

**Why it matters:**
- Useful for quick forms and when you don’t need to manipulate input live.
- Closer to plain HTML form behavior.
- Less React overhead → better performance for large numbers of fields.

⚠️ Downside: Harder to validate or enforce logic during typing (e.g., restricting certain characters).

---

## 3) Controlled vs. Uncontrolled Tradeoffs

| Aspect                | Controlled | Uncontrolled |
|------------------------|------------|--------------|
| **Validation**        | Easy, inline | Harder, must check at submit |
| **Performance**       | More renders | Better performance |
| **Complexity**        | Simple state-driven | Relies on refs |
| **Integration**       | Great with React state | Closer to native DOM |

**Rule of Thumb:**  
- Use **controlled** inputs when you need **real-time validation, dynamic rules, or instant feedback**.  
- Use **uncontrolled** inputs when you only need the value at **submission time** or are dealing with **massive forms**.

---

## 4) Handling Multiple Inputs

A common pattern is controlled forms with multiple fields:

```jsx
function MultiFieldForm() {
  const [form, setForm] = React.useState({ email: "", password: "" });

const handleChange = (e) => {
    const { name, value } = e.target;
    setForm((prev) => ({ ...prev, [name]: value }));
  };

return (
    <form>
      <input name="email" value={form.email} onChange={handleChange} />
      <input name="password" value={form.password} onChange={handleChange} />
    </form>
  );
}
```

This is the **basis of most form libraries**. They automate and optimize this pattern.

---

## ✅ 5) Validation Strategies

### Inline Validation
```jsx
<input
  value={name}
  onChange={(e) => {
    const v = e.target.value;
    if (/^[a-zA-Z]*$/.test(v)) setName(v); // only letters
  }}
/>
```

### On Submit Validation
```jsx
const handleSubmit = (e) => {
  e.preventDefault();
  if (!email.includes("@")) {
    alert("Invalid email");
  }
};
```

**Takeaway:** Controlled inputs make **live validation** trivial. Uncontrolled inputs often require **submission-time validation**.

---

## 6) Enter Form Libraries (React Hook Form, Formik)

While controlled/uncontrolled are the **core building blocks**, libraries exist to solve performance and scalability issues.

### React Hook Form (RHF)
- Uses uncontrolled inputs under the hood for **performance**.
- Minimal re-renders even with large forms.
- Built-in integration with validation libraries like Zod.

```jsx
import { useForm } from "react-hook-form";

function RHFForm() {
  const { register, handleSubmit } = useForm();
  const onSubmit = (data) => console.log(data);

return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("email")} />
      <input type="password" {...register("password")} />
      <button type="submit">Submit</button>
    </form>
  );
}
```

### Formik
- Popular alternative, built around controlled inputs.
- Rich ecosystem but can re-render more often than RHF.

---

## 7) Schema Validation with Zod

Combine form libraries with schema validators like **Zod** for type-safe, declarative validation.

```jsx
import { z } from "zod";
import { zodResolver } from "@hookform/resolvers/zod";
import { useForm } from "react-hook-form";

const schema = z.object({
  email: z.string().email(),
  password: z.string().min(6)
});

function ZodForm() {
  const { register, handleSubmit, formState: { errors } } = useForm({
    resolver: zodResolver(schema)
  });

return (
    <form onSubmit={handleSubmit(console.log)}>
      <input {...register("email")} />
      {errors.email && <p>{errors.email.message}</p>}
      <input type="password" {...register("password")} />
      {errors.password && <p>{errors.password.message}</p>}
    </form>
  );
}
```

---

## 8) Real-World Considerations

- **Large forms (checkout, onboarding):** prefer RHF (uncontrolled under the hood).
- **Dynamic forms (fields added/removed):** controlled state helps.
- **Performance bottlenecks:** uncontrolled refs or RHF optimize rendering.
- **TypeScript projects:** schema validation with Zod ensures type safety end-to-end.

---

## TL;DR

- **Controlled = React owns the state** → best for validation, dynamic logic, instant feedback.  
- **Uncontrolled = DOM owns the state** → best for performance and simple submission.  
- **Libraries like RHF** combine the best of both worlds.  
- **Validation libraries like Zod** bring type safety and maintainable rules.

---

### Up Next: Part 14: Testing React Applications
We’ll dive into unit vs integration testing, tools like React Testing Library, mocking fetches with MSW, and writing tests that reflect user behavior.

---

# Part 14: Testing React Applications: From Basics to Best Practices

Testing isn’t just about finding bugs. It’s about **building confidence** that your React application works as intended, today and tomorrow. A well-tested app is easier to maintain, safer to refactor, and more resilient to changes in requirements.

In this section, we’ll cover the fundamentals of testing React applications, explore popular tools, and look at real-world strategies.

---

## 1) Why Testing Matters in React

- **Confidence**: Prevent regressions when refactoring or upgrading dependencies.
- **Documentation**: Tests often act as living documentation of how components are expected to behave.
- **Collaboration**: Helps teams onboard faster. Tests show intent.
- **Resilience**: Prevents shipping broken features to users.

---

## 2) Types of Tests in React

| Type               | Scope                            | Example                                              | Tools |
|--------------------|----------------------------------|------------------------------------------------------|-------|
| **Unit Tests**     | Smallest pieces (functions, hooks, components) | Testing a custom hook returns correct state          | Jest, Vitest |
| **Integration**    | Multiple units working together  | A form component validating inputs                   | React Testing Library |
| **End-to-End (E2E)** | Full user flows in the browser  | Login → navigate → checkout                          | Cypress, Playwright |

A **healthy test pyramid** emphasizes unit & integration tests at the base, with fewer (but critical) E2E tests at the top.

---

## 3) Testing Tools You’ll Use

- **Jest** (or **Vitest**): Test runner, mocking, assertions.
- **React Testing Library (RTL)**: Encourages testing components as a user would interact with them (not implementation details).
- **MSW (Mock Service Worker):** Mock API requests at the network level.
- **Cypress/Playwright:** Browser automation for E2E.

---

## 4) Unit Testing Components

Let’s test a simple `Counter` component.

```jsx
function Counter() {
  const [count, setCount] = React.useState(0);
  return (
    <>
      <p>Count: {count}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
    </>
  );
}
```

**Test with React Testing Library + Jest:**

```jsx
import { render, screen, fireEvent } from "@testing-library/react";
import Counter from "./Counter";

test("increments count when button clicked", () => {
  render(<Counter />);
  fireEvent.click(screen.getByText(/increment/i));
  expect(screen.getByText(/count: 1/i)).toBeInTheDocument();
});
```

✅ Notice we don’t check internal state. We test what the **user sees**.

---

## 5) Integration Testing

Now let’s test a form with validation:

```jsx
function LoginForm({ onSubmit }) {
  const [email, setEmail] = React.useState("");

return (
    <form onSubmit={(e) => { e.preventDefault(); onSubmit(email); }}>
      <input
        placeholder="Email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <button type="submit">Login</button>
    </form>
  );
}
```

**Integration Test:**

```jsx
test("calls onSubmit with email", () => {
  const mockSubmit = jest.fn();
  render(<LoginForm onSubmit={mockSubmit} />);

fireEvent.change(screen.getByPlaceholderText(/email/i), {
    target: { value: "user@example.com" }
  });
  fireEvent.click(screen.getByText(/login/i));

expect(mockSubmit).toHaveBeenCalledWith("user@example.com");
});
```

Here we test **multiple parts interacting**: input + form + callback.

---

## 6) Mocking APIs with MSW

Real apps fetch data. Instead of hitting a live API in tests, use **MSW** to mock network responses.

```jsx
import { rest } from "msw";
import { setupServer } from "msw/node";

const server = setupServer(
  rest.get("/api/user", (req, res, ctx) =>
    res(ctx.json({ name: "Alice" }))
  )
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());
```

Now your tests can safely run with predictable API responses.

---

## 7) End-to-End Testing (E2E)

Use **Cypress** or **Playwright** to test **real browser interactions**.

**Example (Cypress):**

```js
describe("Login flow", () => {
  it("allows user to login", () => {
    cy.visit("/login");
    cy.get("input[placeholder='Email']").type("test@example.com");
    cy.get("button[type='submit']").click();
    cy.contains("Welcome, test@example.com").should("exist");
  });
});
```

E2E tests are slower, but invaluable for ensuring critical flows like checkout, login, and navigation work end-to-end.

---

## 8) Real-World Testing Strategies

- **Focus on user behavior, not implementation details.**
- **Keep tests isolated.** No test should depend on another.
- **Use E2E for the “happy path”**: critical journeys users rely on.
- **Run tests in CI/CD pipelines** to catch issues early.
- **Balance speed and depth:** Fast unit tests + a few thorough E2E tests.

---

## TL;DR

- **Unit tests** validate small pieces (hooks, utils, components).  
- **Integration tests** ensure parts work together.  
- **E2E tests** validate full flows in the browser.  
- **Tools like RTL, Jest, MSW, and Cypress** are your main arsenal.  
- Test like a **user interacts**, not like a dev peeks at internal state.

---

### Up Next: Part 15: Performance Optimization in React
We’ll cover React DevTools, memoization strategies, code splitting, lazy loading, and how to make React apps **feel snappy at scale**.

---

# Part 15: Performance in React: Practical Playbook + Architectural Tradeoffs

Performance is a **discipline**, not a bag of tricks. This part blends the **day-to-day techniques** a React dev uses (profiling, memoization, virtualization, data caching) with **bigger-picture decisions** (SSR vs SSG vs CSR, server components vs client, where state should live). The goal: keep UX **fast and resilient** as features grow.

---

## 0) The Performance Loop (Mindset)

1) **Measure** a real user flow (Profiler, Performance tab, field metrics).  
2) **Find the hot spots** (slow commits, long tasks, big bundles).  
3) **Fix the right layer** (render churn, data layer, network, images, architecture).  
4) **Re-measure** and repeat.

> Optimization without measurement is guesswork.

---

## 1) Rendering: Reduce Work, Stabilize Identity

### A. Colocate state; slice the tree
- State in a parent re-renders children. Move state **closer** to where it’s used.
- Split big components into **smaller islands**.

```jsx
const Summary = React.memo(({ total }) => <div>Total: {total}</div>);

function Cart({ items }) {
  const total = React.useMemo(
    () => items.reduce((s, it) => s + it.qty * it.price, 0),
    [items]
  );
  return (
    <>
      <ItemList items={items} />  {/* only when items change */}
      <Summary total={total} />   {/* isolated */}
    </>
  );
}
```

### B. Stabilize props for memoized children
- `React.memo` + **stable function/object identity** via `useCallback`/`useMemo`.

```jsx
const Row = React.memo(({ item, onSelect }) => (
  <li onClick={() => onSelect(item.id)}>{item.name}</li>
));

function List({ items, onPick }) {
  const onSelect = React.useCallback((id) => onPick(id), [onPick]);
  return <ul>{items.map(i => <Row key={i.id} item={i} onSelect={onSelect} />)}</ul>;
}
```

### C. Avoid unnecessary derived state
- Compute in render; memoize only if it’s expensive or used as a prop key.

---

## 2) Memoization: Use it Where it Pays

### A. `useMemo` (values)
- Use for **expensive** computations and to keep array/object identity stable.

```jsx
const filtered = React.useMemo(
  () => data.filter(d => match(d, query)).sort(sorter),
  [data, query, sorter]
);
```

### B. `useCallback` (functions)
- Use when child memoization relies on **stable function props**.

### C. When **not** to memoize
- Cheap computations and rarely rendered components. Memoization adds overhead and complexity.

---

## 3) Concurrency: Keep Interactions Snappy

React 18 tools for prioritization:

### A. `startTransition`: mark non-urgent updates
```jsx
import { startTransition } from "react";

function Search({ list }) {
  const [q, setQ] = React.useState("");
  const [res, setRes] = React.useState(list);

### B. `useDeferredValue`: reuse last value while new one resolves
```jsx
const deferredQ = React.useDeferredValue(q);
const results = React.useMemo(() => heavyFilter(list, deferredQ), [list, deferredQ]);
```

---

## 4) Lists: Virtualize and Key Correctly

### A. Virtualization (react-window / react-virtualized)
Render only what’s visible. It’s often the **biggest single win**.

```jsx
import { FixedSizeList as List } from "react-window";
<List height={500} itemCount={rows.length} itemSize={40} width={600}>
  {({ index, style }) => <div style={style}>{rows[index].label}</div>}
</List>
```

### B. Stable keys
- Use **stable IDs** (`key={item.id}`), not array indexes. Prevents focus jumps and state leakage.

---

## 5) Data Layer: Cache, Revalidate, Avoid Refetch Storms

### A. Use a query library (React Query / SWR)
- Caching, dedupe, retries, SWR, pagination, optimistic updates.

```jsx
const { data, isLoading } = useQuery({
  queryKey: ["users"],
  queryFn: () => fetch("/api/users").then(r => r.json()),
  staleTime: 60_000,
});
```

### B. Optimistic mutations with rollback (snappy UX)
- Update cache first, revert on error, invalidate narrowly.

### C. Move “server state” out of React state
- Use the data cache for server data; React state for local UI only.

---

## 6) Loading UX: Suspense, Skeletons, Streaming

### A. Suspense for **code splitting**
```jsx
const Chart = React.lazy(() => import("./Chart"));
<React.Suspense fallback={<ChartSkeleton />}>
  <Chart />
</React.Suspense>
```

### B. Suspense for data
- Prefer framework/library support (React Router `defer`, Next.js Server Components) to suspend and **progressively reveal** UI.
- Pair with **Error Boundaries** for robust fallback flows.

### C. Skeletons > spinners
- Skeletons communicate structure and feel faster than generic spinners.

---

## 7) Architecture: CSR vs SSR vs SSG vs RSC

### A. Client-Side Rendering (CSR)
- All logic in browser; simplest deploy; **slowest first paint** for heavy apps.
- Improve with code splitting and caching.

### B. Server-Side Rendering (SSR)
- HTML generated per request; **faster first contentful paint**, great for SEO.
- Requires hydration; careful with data waterfalls and caches.

### C. Static Site Generation (SSG)
- Pre-render at build time; **fastest delivery**; best when content changes infrequently.
- Use **ISR** (incremental static regeneration) for periodic freshness.

### D. React Server Components (RSC) / Server-first (e.g., Next.js App Router)
- Render components on the server; send lightweight payloads.
- **Smaller client bundles**, built-in streaming & Suspense.
- Keep client components for interactivity; push data fetching to server where possible.

> **Rule of thumb:** If you can render it on the server without losing interactivity, do it. Ship **less JS** to the client.

---

## 8) Bundles: Load Only What You Need

### A. Analyze
- Vite: `--report` or plugins, Next.js: `next build` output, Webpack: `webpack-bundle-analyzer`.

### B. Split & lazy-load
- Route-level and component-level code splitting.
- Prefer **dynamic imports** for heavy/rarely-used components.

### C. Tree-shaking & dependencies
- Prefer ESM builds, avoid importing “kitchen sink” modules.
- For icons, import per-icon, not whole packs.

---

## 9) Images, Fonts, and Assets

### A. Responsive images
```html
<img
  src="/img/600.jpg"
  srcset="/img/600.jpg 600w, /img/1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="Preview"
  loading="lazy"
  decoding="async"
/>
```

### B. Fonts
- Use **font-display: swap**.
- Preload critical fonts (`<link rel="preload" as="font" ...>`).
- Consider **system fonts** for perf-critical surfaces.

### C. CSS
- Avoid blocking CSS. Extract critical CSS where needed (frameworks do this well).

---

## 10) Off-Main-Thread & Expensive Work

### A. Web Workers / Comlink
- Push CPU-heavy tasks off the UI thread to avoid jank.

### B. Throttle & debounce
- Throttle scroll/resize; debounce search inputs.

```js
function debounce(fn, ms=200){let t;return (...a)=>{clearTimeout(t);t=setTimeout(()=>fn(...a),ms)};}
```

### C. requestAnimationFrame
- For animation-aligned updates, `requestAnimationFrame` ensures work happens before paint.

---

## 11) Context & Renders: Avoid the “Giant Provider” Trap

- Split contexts by concern (auth, theme, settings).  
- Memoize provider values:
```jsx
const value = React.useMemo(() => ({ user, signOut }), [user]);
```
- Consider selector-based contexts or external stores (Zustand) when many consumers depend on small slices.

---

## 12) Profiling & Diagnostics (Hands-on)

### A. React DevTools Profiler
- Record typing, filtering, or route changes.
- Inspect why a component rendered (state/props/context changed).

### B. “Why Did You Render”
- A dev-only helper to warn about re-renders with identical props.

### C. Performance panel
- Look for **Long Tasks** (>50ms), layout thrash, heavy scripting.
- Record CPU throttled profiles to simulate low-end devices.

---

## 13) Practical Playbook (Common Scenarios)

### Scenario: “Typing in a search box is laggy”
- Debounce API calls.
- `startTransition` for heavy filtering.
- Virtualize results list.
- Memoize filter results and keep handler identities stable.

### Scenario: “Navigating between routes is slow”
- Code-split routes, prefetch on hover.
- Use route loaders (or Server Components) to avoid fetch-on-mount waterfalls.
- Skeletons for below-the-fold sections.

### Scenario: “Dashboard charts jank when resizing”
- Throttle resize handlers.
- Use `useMemo` for dataset transformations.
- Lazy-load chart libs behind Suspense.

### Scenario: “Infinite feed stutters”
- Virtualize.
- Cache pages; use React Query’s `getNextPageParam`.
- Avoid re-rendering parent on every scroll tick.

---

## 14) Checklists

### Rendering & Hooks
- [ ] State colocated; components sliced  
- [ ] `React.memo` for leaf/heavy components  
- [ ] `useMemo`/`useCallback` for expensive or identity-sensitive props  
- [ ] `startTransition` / `useDeferredValue` for responsive input

### Data & Routing
- [ ] Query library for server data; smart `staleTime`  
- [ ] Route loaders / server components to avoid waterfalls  
- [ ] Optimistic updates for snappy UX

### Assets & Bundles
- [ ] Code-splitting & lazy loading for heavy components  
- [ ] Bundle analysis done; large deps trimmed  
- [ ] Responsive images; lazy loading; font optimization

### Robustness
- [ ] Suspense localized with meaningful skeletons  
- [ ] Error Boundaries paired with Suspense  
- [ ] E2E tests on critical flows to prevent perf regressions

---

## TL;DR

- **Measure first**, fix the **right layer**.  
- Reduce re-renders with **state colocation**, **memoization**, and **virtualization**.  
- Use **concurrency** (`startTransition`, `useDeferredValue`) to keep input responsive.  
- **Cache server data** and avoid fetch storms; prefer route loaders/server components.  
- Ship **less JS**: code-split, optimize bundles, leverage server rendering.  
- Treat images, fonts, and workers as **first-class performance tools**.

---

### What’s Next
Wrap the series with **final summary + curated resources + practice projects**: performance checklists, repo templates, and labs (virtualized table, Suspense dashboard, server-first conversions). Want me to generate that final section now?

---

# Final Wrap-Up: Your React Roadmap to Confident, Production-Ready Skills

You’ve just walked through React from **first render to production**: state & effects, keys & forms, custom hooks, performance, routing, data fetching, accessibility, testing, design patterns, and architectural tradeoffs. This isn’t random trivia. It’s a **map**. Use it to build apps that are fast, accessible, and maintainable.

Below is a concise **field guide** you can revisit as you build. Keep shipping. Keep measuring. Keep improving.

---

## Big Ideas to Keep Forever

- **React is just functions + data flow.** Components re-run when **state/props/context** change.
- **Identity matters.** Stable keys, stable objects/callbacks → predictable renders & perf.
- **State belongs as low as possible.** Lift state only when multiple peers need it.
- **Effects sync with the outside world.** Clean up, cancel, and keep deps honest.
- **Composition > configuration.** Compose components and hooks; avoid giant prop bags.
- **Server vs client responsibilities.** Push fetch/compute to the server when it helps bundle size & UX.
- **Measure before optimizing.** Profiler, Performance tab, field metrics. Fix hot paths first.
- **Accessibility & testing are features.** Bake them in; don’t bolt them on.

---

## A Practical Learning Path (Do This in Order)

1) **Foundations**
   - Build a small app (todos, notes). Use `useState`, props, lists with stable keys.
   - Practice controlled vs uncontrolled inputs; simple validation.

2) **Effects & Data**
   - Add `useEffect` for fetch, with cleanup & cancellation.
   - Upgrade to **React Router** (layouts, params) or **Next.js** (App Router basics).

3) **Hooks & Reuse**
   - Extract logic into **custom hooks** (debounce, viewport, fetch wrappers).
   - Build **compound/headless** components (Tabs, Modal) with accessibility.

4) **Data Layer & Mutations**
   - Adopt **React Query/SWR**: caching, revalidation, optimistic updates, infinite queries.

5) **Performance**
   - Profile a real flow. Add `React.memo`, `useMemo`, `useCallback` where it pays.
   - Virtualize long lists, code-split heavy routes/widgets, try `startTransition`.

6) **Quality**
   - **RTL + MSW** integration tests for key screens.
   - Add **Error Boundaries** + **Suspense** fallbacks. Check a11y with `jest-axe`.

7) **Architecture**
   - Choose SSR/SSG/RSC where appropriate. Keep server state in a cache, local UI state in React.
   - Modularize folders by **feature/domain** rather than file type.

Ship something at each step. Small, real projects > endless reading.

---

## Daily Developer Checklist

**Rendering & State**
- [ ] Keys are **stable IDs** (never indexes)  
- [ ] State colocated; no duplicated/derived state stored  
- [ ] Heavy calculations memoized (`useMemo`), hot handlers stabilized (`useCallback`)  
- [ ] Components that benefit are wrapped in `React.memo`

**Effects & Data**
- [ ] `useEffect` cleans up (timers, listeners, AbortController)  
- [ ] Fetching uses **React Query/SWR** (cache, retry, SWR)  
- [ ] Mutations are optimistic where it improves UX  
- [ ] Errors surfaced with boundaries; user has a retry

**UX & A11y**
- [ ] Skeletons over spinners; focus managed on route/modal open  
- [ ] Semantic roles/labels present; keyboard flows tested  
- [ ] Color contrast & focus outlines visible

**Performance**
- [ ] Critical flows profiled; long lists virtualized  
- [ ] Route/components code-split; heavy libs lazy-loaded  
- [ ] `startTransition`/`useDeferredValue` used for expensive, non-urgent updates

**Quality**
- [ ] RTL tests cover core flows; MSW mocks API  
- [ ] E2E covers login, primary user path, and one failure case  
- [ ] CI runs tests & linting; perf budgets/bundle analysis checked

---

## Interview & Real-World Q&A Drills (Practice Weekly)

- **Props vs State:** When to lift, when to derive.  
- **Keys:** Why not indexes? Show a bug and fix it.  
- **useEffect:** Dependencies, cleanup, cancellation; show a race condition fix.  
- **Forms:** Controlled vs uncontrolled; RHF with Zod.  
- **Performance:** Explain a real optimization you profiled and implemented.  
- **Routing:** Nested layouts, loaders/actions (or Next.js server components), error boundaries.  
- **Data:** SWR/React Query mental model; optimistic updates; infinite queries.  
- **Suspense:** Code splitting today, data with router/framework support tomorrow.

Write your answers as **mini code demos**. Rehearse them like stories.

---

## Curated Resources (Small, High-Value Set)

- **React Docs:** Learn, Reference sections (official, thorough).  
- **React Router:** Nested routes, loaders, defer/Await.  
- **TanStack Query:** Guides on caching, mutations, infinite queries.  
- **Testing Library:** “Testing library principles” doc.  
- **Accessibility:** WAI-ARIA Authoring Practices; WebAIM contrast checker.  
- **Performance:** React DevTools Profiler docs; “web.dev/metrics” for Core Web Vitals.

(Keep a personal notes repo with code snippets and “why it matters” summaries.)

---

## Capstone Practice Projects (Portfolio-Ready)

1) **Real-Time Dashboard**
   - Server data via React Query, background refresh
   - Virtualized tables, lazy-loaded charts, Suspense boundaries
   - Error boundaries with retry; a11y on live regions

2) **E-commerce Mini**
   - Routing with nested layouts, product pages with loaders/defer
   - Cart & checkout forms (RHF + Zod)
   - Optimistic add-to-cart, SSR/SSG (or Next.js App Router)

3) **Team Kanban**
   - Drag-and-drop board (keyboard accessible)
   - Optimistic mutations, infinite queries for activity feed
   - Feature-based folder structure, RTL/MSW test suite

Write a README that explains your **tradeoffs** (CSR vs SSR, caching choices, perf work).

---

## Final Motivation

You don’t need secret tricks. You need **clarity** and **reps**. The developers who excel aren’t the ones who memorize every hook; they’re the ones who can:

- Explain **why a render happened**,  
- Choose **where state should live**,  
- Build **predictable data flows**,  
- Measure and fix **real** bottlenecks, and  
- Deliver features that are **fast, accessible, and tested**.

Start small, ship often, measure honestly. In a few months, you won’t just be “using React”. you’ll be **designing systems** with it.

You’ve got this. Now go build something users love.
</article></body></html>