React.js Framework – Complete Notes

// Old way (plain JavaScript)
let count = 0;
btn.onclick = () => { count++; btn.textContent = `Clicked ${count} times`; };

// React way
import { useState } from 'react';
function ClickCounter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

• Declarative code: You write what the UI should be, not the steps to change it. Code is shorter and easier to read.
• Component reusability: A button, card, or modal written once can be used hundreds of times.
• Automatic UI syncing: State changes automatically trigger re-renders.
• Excellent performance: Virtual DOM diffing minimises expensive real DOM operations.
• Huge ecosystem: React Router, Redux Toolkit, TanStack Query, Next.js, and thousands of libraries.
• Strong community and jobs market: Massive Stack Overflow presence and hiring demand.
• Testability: Components are pure functions of props and state.
• Learn once, write anywhere: Same mental model for web and mobile via React Native.
• Backed by Meta: Long-term stability and continuous innovation (Hooks, Concurrent mode, Server Components).

• It is only the view layer: You must choose extra libraries for routing, forms, and state.
• JSX learning curve: Mixing HTML-like syntax with JavaScript confuses beginners at first.
• Rapid ecosystem churn: Best practices change often (classes → hooks → server components); tutorials go stale.
• Boilerplate for small apps: A tiny static site needs Vite, npm, and bundlers.
• SEO and initial load (CSR): Pure client-side React can hurt SEO without SSR/SSG.
• State management complexity: In large apps, prop drilling and context performance issues appear.
• Over-rendering risk: Without care, components re-render too often and hurt performance.
• Not a full framework: No built-in opinion on file structure, so teams can build inconsistent codebases.

• Component-based architecture: The UI is a tree of independent, composable components.
• Declarative programming style: Describe the result, not the procedure.
• Virtual DOM: An in-memory representation of the real DOM used for fast diffing.
• Unidirectional data flow: Data moves down via props; events move up via callbacks.
• JSX: A syntax extension that lets you write markup inside JavaScript.
• Props and State: Props are read-only inputs; state is mutable internal data.
• Hooks: Functions like useState and useEffect that add state and side effects to function components.
• Composition over inheritance: Components are combined, not subclassed.
• Just JavaScript: Conditions and loops use normal JS.
• Rich developer tooling: React DevTools, Fast Refresh, and error overlays.

                 ┌──────────────────┐
                 │    App (Root)    │
                 └────────┬─────────┘
                          │
          ┌───────────────┴───────────────┐
          │                               │
     ┌────▼─────┐                   ┌─────▼──────┐
     │  Header  │                   │    Main    │
     └────┬─────┘                   └─────┬──────┘
          │                               │
     ┌────▼─────┐              ┌──────────┴──────────┐
     │   Logo   │         ┌────▼────┐          ┌─────▼─────┐
     └──────────┘         │ Counter │          │ TodoList  │
                          └─────────┘          └───────────┘

  State / Props change
           │
           ▼
  ┌─────────────────────┐
  │  New Virtual DOM    │
  │  (JS object tree)   │
  └──────────┬──────────┘
             │  diff / reconcile
  ┌──────────▼──────────┐
  │ Compare with old    │
  │ Virtual DOM         │
  └──────────┬──────────┘
             │
             ▼
  ┌─────────────────────┐
  │ Minimal real DOM    │
  │ updates only        │
  └─────────────────────┘

  One-way data flow:
   Parent  ──── props (data down) ────►  Child
   Parent  ◄─── callback (events up) ───  Child

1. In your own words, explain the difference between declarative and imperative UI programming with one example each.
2. Create a new React project using npm create vite@latest my-app -- --template react and run the dev server.
3. Write a Greeting component that accepts a name prop and renders “Hello, <name>!”.
4. Build a LikeButton component that shows “Likes: 0” and increments on click.
5. Show “You liked this!” once the count is greater than zero.
6. Build an App with Header, Greeting, and two independent LikeButtons.
7. List three problems React does not solve on its own, and name one library for each.

// Simple component with a prop
function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// Component using children for composition
function Card({ title, children }) {
  return (
    <div className="card">
      <h3>{title}</h3>
      <div className="card-body">{children}</div>
    </div>
  );
}

// Using both
function App() {
  return (
    <div>
      <Greeting name="Amit" />
      <Greeting name="Priya" />

      <Card title="Welcome">
        <p>This is inside the Card.</p>
        <button>Click me</button>
      </Card>
    </div>
  );
}

• Reusability: Write once, use hundreds of times. Reduces code duplication.
• Composition: Build complex UIs from simple pieces using children.
• Testability: Each component can be tested in isolation.
• Clear data flow: Data flows down through props; events bubble up via callbacks.
• Team collaboration: One team can own one component end-to-end.
• Separation of concerns: Business logic can live in container components; presentation in presentational ones.

• Prop drilling: In deep trees, passing props through many levels becomes tedious.
• Over-splitting: Too many tiny components make many files and hurt readability.
• Naming confusion: Poorly named components blur responsibility.
• Re-render cost: If props change frequently, components re-render often.
• JSX learning curve: New developers may find JSX syntax unusual at first.

• Props are immutable: A child must never modify its props.
• Children is a special prop: Used for nesting other JSX.
• Single root element: Components return one root element, or a Fragment (<>...</>).
• Names must be Capitalised: React treats lowercase tags as HTML elements.
• Composition over inheritance: Prefer passing elements and functions over subclassing.
• Pure rendering: Given the same props, a component should render the same output.

   Parent  ──── props (data down) ────►  Child
   Parent  ◄─── callback (events up) ───  Child

Component Tree:

<App>
 ├─ <Header title="My Site" />
 ├─ <Card title="Welcome">
 │    ├─ <p>Hello World</p>
 │    └─ <Button label="OK" onClick={handleOk} />
 └─ <Footer year={2025} />

Composition:
  <Card>
    └─ children = whatever you put inside
  </Card>

1. Build a Card component that accepts title and children.
2. Build a Button component with label and onClick props.
3. Create a UserList that receives an array of users via props.
4. Explain why props are read-only.
5. Convert a repeated HTML block into a reusable component.

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  const [items, setItems] = useState([]);

  const addItem = () => {
    // Correct: create a NEW array
    setItems(prev => [...prev, `Item ${prev.length + 1}`]);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
      <button onClick={() => setCount(0)}>Reset</button>

      <button onClick={addItem}>Add item</button>
      <ul>
        {items.map((item, i) => <li key={i}>{item}</li>)}
      </ul>
    </div>
  );
}

• UI stays in sync: State changes automatically re-render the component.
• Simple API: useState is easy to learn and use.
• Colocation: State lives close to where it's used.
• Predictable updates: Updates go through the setter, making state changes traceable.
• Composable: Multiple useState calls can coexist cleanly.

• Async updates: Reading state right after setting gives the old value.
• Mutating directly does nothing: Must always create new objects or arrays.
• Prop drilling: Lifting state too high causes verbose prop passing.
• Too much state: Many pieces of state in one component make it complex.
• Easy to store derived values: Which causes bugs when they drift out of sync.

• Each useState returns [value, setter].
• Setter can take a value or an updater function: setCount(c => c + 1).
• Updates are batched: Multiple setState calls in one event are combined for performance.
• Immutable: Never mutate objects/arrays — create new ones.
• Re-renders trigger: When the value changes by reference or primitive equality.

setCount(count + 1)
        │
        ▼
  State updated
        │
        ▼
  Component re-renders
        │
        ▼
  New JSX → diff → DOM updated

Immutable update pattern:

  // Wrong
  items.push(newItem);      // no re-render
  setItems(items);

  // Correct
  setItems([...items, newItem]);
  // or
  setItems(prev => [...prev, newItem]);

1. Build a Toggle component using state (on/off).
2. Build a Temperature component with Celsius/Fahrenheit conversion.
3. Explain why count = count + 1 does not re-render.
4. Update an array in state by adding a new item immutably.
5. Update an object in state immutably (e.g., change a user's name).

import { useState, useEffect, useRef } from 'react';

function Timer() {
  const [seconds, setSeconds] = useState(0);
  const intervalRef = useRef(null);

  useEffect(() => {
    intervalRef.current = setInterval(() => {
      setSeconds(s => s + 1);
    }, 1000);

    return () => clearInterval(intervalRef.current);
  }, []);

  return <p>Seconds: {seconds}</p>;
}

• State in function components: No need for classes.
• Custom hooks: Reuse stateful logic cleanly across components.
• Less boilerplate: No constructor or lifecycle method ceremony.
• Related logic together: Group effects by concern, not by lifecycle method.
• Composable: One hook can call another.
• Better testability: Hooks and components are plain functions.

• Rules of hooks: Must be followed exactly, or bugs appear.
• Dependency arrays: Easy to get wrong, cause stale values or loops.
• Stale closures: Effects capture values from the render they were created in.
• Overusing useMemo/useCallback: Adds complexity without benefit.
• Learning curve: Understanding hooks deeply takes time.

• Consistent order: Hooks are called in the same order on every render.
• Custom hooks: Functions whose names start with use.
• Compose: Built-in hooks can be used inside custom hooks.
• Top-level only: Cannot be called inside conditions, loops, or nested functions.
• React functions only: Cannot be called inside plain JS functions.

function Component() {
  const [a] = useState(0);   // hook 1
  const [b] = useState(1);   // hook 2
  useEffect(() => {}, []);   // hook 3
  // Order MUST remain the same every render
}

Custom Hook Example:

function useWindowWidth() {
  const [w, setW] = useState(window.innerWidth);
  useEffect(() => {
    const handler = () => setW(window.innerWidth);
    window.addEventListener('resize', handler);
    return () => window.removeEventListener('resize', handler);
  }, []);
  return w;
}

1. Write a custom hook useWindowWidth.
2. Write a custom hook useLocalStorage.
3. Explain why hooks cannot be called inside conditions or loops.
4. Convert a class component with lifecycle methods into a function component with hooks.
5. Use useReducer to build a shopping cart.

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

  async function load() {
    try {
      const res = await fetch('/api/users', { signal: controller.signal });
      const data = await res.json();
      setUsers(data);
    } catch (err) {
      if (err.name !== 'AbortError') setError(err);
    }
  }
  load();

  return () => controller.abort();
}, []);

• Clear place for side effects: All side effects are inside useEffect, not scattered.
• Cleanup prevents leaks: Timers, listeners, and requests are properly cancelled.
• Fine control: Dependency array gives precise control over execution.
• Works with async data: Standard pattern for API calls.
• Composable: Multiple effects can coexist, each with its own concern.

• Dependency arrays easy to get wrong: Missing deps cause stale data; extra deps cause loops.
• Race conditions: Async fetches need AbortController or a similar guard.
• Closures: Effects capture values from the render they were created in.
• Overuse: Many effects in one component make it hard to reason about.
• Not for derived state: Use useMemo for computing instead.

• Runs after paint: Effects do not block the browser's paint.
• Cleanup runs first: Before each subsequent effect, and on unmount.
• One concern per effect: Separate effects for unrelated logic.
• Async patterns: Do not make the effect function async directly; define an inner async function.
• AbortController: Standard way to cancel fetches.

Mount → Render → Paint → useEffect runs
                              │
                              ▼
                        (dep changes)
                              │
                              ▼
                        cleanup runs
                              │
                              ▼
                        useEffect runs again
                              │
                              ▼
                        Unmount → cleanup runs last

Race condition guard:

  1. useEffect starts fetch A (dep = 1)
  2. dep changes to 2 → cleanup aborts fetch A
  3. useEffect starts fetch B (dep = 2)
  4. Only B's result is applied

1. Build a clock component using useEffect and setInterval.
2. Fetch data from a public API and display it with loading and error states.
3. Add a window resize listener with proper cleanup.
4. Explain why missing cleanup causes memory leaks.
5. Implement a fetch with AbortController to avoid race conditions.

<Tabs>
  <Tabs.List>
    <Tabs.Tab>One</Tabs.Tab>
    <Tabs.Tab>Two</Tabs.Tab>
  </Tabs.List>
  <Tabs.Panels>
    <Tabs.Panel>Content 1</Tabs.Panel>
    <Tabs.Panel>Content 2</Tabs.Panel>
  </Tabs.Panels>
</Tabs>

• Reusable, proven solutions: Avoid reinventing structural problems.
• Better separation of concerns: Logic and UI can be split cleanly.
• Easier testing and maintenance: Well-known patterns are predictable.
• Improved UX: Error boundaries and Suspense make apps robust.
• Flexibility: Compound components give users a natural API.

• HOCs create wrapper hell: Deep nesting and prop collisions.
• Render props can nest deeply: Difficult to read in extreme cases.
• Compound components require care: Context design must be right.
• Over-engineering: Simple components suffer from too many patterns.
• Learning curve: Each pattern has its own semantics.

• Patterns compose: You can combine HOC + Context + Error Boundary.
• Custom hooks often replace HOC / render props: Modern React prefers hooks.
• Portals use ReactDOM.createPortal: Still respect React event bubbling.
• Error boundaries use class components: componentDidCatch / getDerivedStateFromError.
• Suspense: Works with React.lazy and query libraries.

<App>
  <ErrorBoundary>
    <Main />
    {ReactDOM.createPortal(<Modal />, document.body)}
  </ErrorBoundary>
</App>

DOM Tree (portal attaches outside):

  body
   ├── #root
   │    └── App → ErrorBoundary → Main
   └── div.portal-root
        └── Modal

ErrorBoundary flow:

  Child throws
       │
       ▼
  getDerivedStateFromError → set hasError=true
       │
       ▼
  Render fallback UI instead of crashed tree

1. Build a simple ErrorBoundary class component.
2. Build a Modal using a React portal.
3. Implement a compound Accordion component.
4. Convert an HOC to a custom hook and compare the code.
5. Implement a Suspense fallback for a lazy-loaded component.

import { create } from 'zustand';

const useStore = create((set) => ({
  count: 0,
  increment: () => set((s) => ({ count: s.count + 1 })),
  reset: () => set({ count: 0 }),
}));

function Counter() {
  const { count, increment, reset } = useStore();
  return (
    <div>
      <p>{count}</p>
      <button onClick={increment}>+1</button>
      <button onClick={reset}>Reset</button>
    </div>
  );
}

• No prop drilling: Data available anywhere in the tree.
• Central debugging: All state changes pass through one place.
• Server state tools: Caching, dedup, background refetch for free.
• Small libraries: Zustand and Jotai are lightweight and simple.
• DevTools: Redux Toolkit offers time-travel debugging.

• Extra abstraction: Redux adds boilerplate and concepts.
• Wrong tool choice: Causes complexity and slow development.
• Global overuse: Makes testing harder and hides dependencies.
• Context re-renders: All consumers re-render on any change.
• Learning curve: Each library has its own idiom.

• Server state ≠ UI state: Treat separately with the right tool.
• Global UI state should be small: Theme, auth, modals — not the whole app.
• Redux Toolkit: Slices, Immer-based immutability, RTK Query for APIs.
• Zustand/Jotai: Minimal, hook-based stores.
• Context: Great for rarely changing values like theme.

Data needed by one component?   →  useState
Data needed by many components? →  Context + useReducer / Zustand
Data from an API?               →  TanStack Query / SWR
Very large app, strict flow?    →  Redux Toolkit

Layered view:

  ┌──────────────────────────────┐
  │  Server state (TanStack Query)│
  ├──────────────────────────────┤
  │  Global UI state (Zustand)   │
  ├──────────────────────────────┤
  │  Local state (useState)      │
  └──────────────────────────────┘

1. Build a theme toggle with Context + useReducer.
2. Build a todo list with Zustand.
3. Fetch users with TanStack Query and show loading/error states.
4. Compare Redux Toolkit, Zustand, and Context in a short table.
5. Refactor a prop-drilled app to use Context.

import { BrowserRouter, Routes, Route, Navigate } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />

        <Route path="/users" element={<UsersLayout />}>
          <Route index element={<UsersList />} />
          <Route path=":id" element={<UserDetail />} />
        </Route>

        <Route path="/dashboard" element={
          <ProtectedRoute><Dashboard /></ProtectedRoute>
        } />

        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
}

• Real URLs: Back/forward buttons, bookmarks, share links work.
• Fast navigation: No full page reloads.
• Nested layouts: Shared shells for sections of the app.
• Protected routes: Easy auth gating.
• Code splitting per route: Smaller initial bundle.

• Extra dependency: Adds to bundle size.
• Server config: Must serve index.html for all routes.
• SEO limits: Full benefit needs SSR/SSG.
• Complex configs: Deeply nested routes can be hard to follow.

• Route matching by specificity: Not by order.
• Outlet renders children: Used for nested layouts.
• Data APIs: Loaders and actions in v6.4+.
• File-based routing: Next.js and Remix build on the same concepts.
• Lazy loading: Per route via React.lazy.

<BrowserRouter>
 └─ <Routes>
     ├─ "/"              → <Home />
     ├─ "/users"         → <UsersLayout />
     │     ├─ index      → <UsersList />
     │     └─ ":id"      → <UserDetail />
     ├─ "/dashboard"     → <ProtectedRoute> → <Dashboard />
     └─ "*"              → <NotFound />

ProtectedRoute example:

  function ProtectedRoute({ children }) {
    const authed = useAuth();
    return authed ? children : <Navigate to="/login" replace />;
  }

1. Set up React Router with Home, About, and Contact pages.
2. Create a nested route with a shared layout using <Outlet />.
3. Read a route param and query string.
4. Implement a ProtectedRoute that redirects to /login.
5. Lazy-load a route component with Suspense.

import { useForm } from 'react-hook-form';

function LoginForm() {
  const {
    register, handleSubmit,
    formState: { errors, isSubmitting }
  } = useForm();

  const onSubmit = async (data) => {
    await fetch('/api/login', {
      method: 'POST',
      body: JSON.stringify(data),
    });
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input
        {...register('email', {
          required: 'Email is required',
          pattern: { value: /\\S+@\\S+/, message: 'Invalid email' }
        })}
      />
      {errors.email && <span>{errors.email.message}</span>}

      <input
        type="password"
        {...register('password', { required: true, minLength: 8 })}
      />
      {errors.password && <span>Password too short</span>}

      <button disabled={isSubmitting}>
        {isSubmitting ? 'Logging in...' : 'Login'}
      </button>
    </form>
  );
}

• Validation, error display, submission: Handled uniformly.
• Less boilerplate: React Hook Form significantly reduces code.
• Better performance: Uncontrolled inputs avoid re-renders.
• Schema validation: Zod/Yup make rules reusable and typed.
• Loading states: Built-in isSubmitting for UX feedback.

• Controlled forms with many inputs: Cause excessive re-renders.
• Library learning curve: RHF has its own idioms.
• Server validation still required: For security.
• File inputs and complex widgets: Need special handling.
• Debugging uncontrolled inputs: Slightly harder than controlled.

• Client + server validation: Both are required.
• Controlled inputs: Make conditional UI easy.
• Uncontrolled inputs: Lighter but harder to coordinate.
• Disable submit while submitting: Prevent double posts.
• Accessible errors: Use aria-invalid and aria-describedby.

Controlled:
  state ── value ──► input
    ▲                  │
    └──── onChange ◄────┘

Uncontrolled:
  input (DOM holds value)
    │
    └── read via ref on submit

Form submission flow:

  User fills form
        │
        ▼
  Client validation (instant feedback)
        │
        ▼
  POST to server
        │
        ▼
  Server validation (final gate)
        │
        ▼
  Success / error response

1. Build a controlled login form with two fields.
2. Rebuild it with React Hook Form and compare the code.
3. Add client-side validation for email and password length.
4. Add a file upload input and handle it in onSubmit.
5. Integrate Zod schema validation into React Hook Form.

import { useQuery, useMutation, useQueryClient }
  from '@tanstack/react-query';

function Users() {
  const qc = useQueryClient();

  const { data, isLoading, error, refetch } = useQuery({
    queryKey: ['users'],
    queryFn: () => fetch('/api/users').then(r => r.json()),
  });

  const createUser = useMutation({
    mutationFn: (user) => fetch('/api/users', {
      method: 'POST', body: JSON.stringify(user),
    }),
    onSuccess: () => qc.invalidateQueries({ queryKey: ['users'] }),
  });

  if (isLoading) return <Spinner />;
  if (error) return <ErrorMsg error={error} onRetry={refetch} />;

  return (
    <>
      <UserList users={data} />
      <button onClick={() => createUser.mutate({ name: 'New' })}>
        Add User
      </button>
    </>
  );
}

• Caching and dedup: Out of the box.
• Background refetch: Keeps data fresh without user action.
• Standardised states: loading, error, success all uniform.
• Mutations with optimistic updates: Instant UI feedback.
• Pagination and infinite scroll: Dedicated hooks (useInfiniteQuery).
• Retries and cancellation: Configurable out of the box.

• Extra dependency: Learning curve and bundle size.
• Query keys: Must be designed carefully for correct caching.
• Over-fetching: Poor cache strategy wastes bandwidth.
• GraphQL: Needs a well-designed schema and server.
• Another layer: Debugging requires understanding both React and the library.

• Server state ≠ UI state: Treat separately.
• Keys identify cached data: ['users'], ['user', id].
• Mutations invalidate queries: Automatic refetch after data changes.
• AbortController: Cancels in-flight requests.
• Optimistic updates: Show the expected result before the server confirms.

Component mounts
        │
        ▼
useQuery(key, fn)
        │
        ▼
  Cache hit? ── yes → return cached + refetch in background
        │
        no
        ▼
  Fetch → loading → success/error
        │
        ▼
  Cache stored under key
        │
        ▼
  Mutations invalidate → refetch

Optimistic update flow:

  User clicks "Add"
        │
        ▼
  UI shows new item immediately
        │
        ▼
  Server request in background
        │
        ▼
  On success → keep / refetch
  On error   → rollback

1. Fetch a list from a public API using fetch and useState/useEffect.
2. Rebuild the same with TanStack Query and compare the code.
3. Add a mutation that creates a new item and invalidates the list query.
4. Implement infinite scroll with useInfiniteQuery.
5. Add an optimistic update for a like/unlike action.

import { motion, AnimatePresence } from 'framer-motion';

function Modal({ isOpen, onClose, children }) {
  return (
    <AnimatePresence>
      {isOpen && (
        <motion.div
          className="overlay"
          initial={{ opacity: 0 }}
          animate={{ opacity: 1 }}
          exit={{ opacity: 0 }}
          onClick={onClose}
          role="dialog"
          aria-modal="true"
        >
          <motion.div
            className="modal"
            initial={{ y: 40, opacity: 0 }}
            animate={{ y: 0, opacity: 1 }}
            exit={{ y: 40, opacity: 0 }}
            onClick={e => e.stopPropagation()}
          >
            {children}
          </motion.div>
        </motion.div>
      )}
    </AnimatePresence>
  );
}

• Delightful UX: Modern, polished experiences.
• Accessible components: Proven libraries handle ARIA correctly.
• Performance: Virtualization makes huge lists usable.
• Focus management: Improves keyboard and screen-reader UX.
• Reusability: Radix/Headless UI give unstyled primitives.

• Performance risk: Animations can hurt FPS if not optimised.
• Accessibility easy to get wrong: Test with real users.
• Overuse of effects: Overwhelms users.
• Bundle weight: Third-party libraries add size.
• Complexity: Managing modals, focus, and scroll-lock is fiddly.

• Prefer CSS for simple animations: JS for complex choreography.
• Modals should trap focus: Close on Escape.
• Virtualize lists over a few hundred items.
• Follow WAI-ARIA patterns: For interactive widgets.
• Respect prefers-reduced-motion: Disable animations for users who request it.

Open modal
   │
   ▼
Save current focus
   │
   ▼
Focus first focusable element in modal
   │
   ▼
Tab / Shift+Tab cycles inside modal
   │
   ▼
Escape / click overlay → close
   │
   ▼
Restore previous focus

Virtualized list rendering:

  Full list (10,000 items):
   [1] [2] [3] ... [10000]

  Virtualized (visible window only):
   [9998] [9999] [10000]  ← rendered
   rest is placeholder space

1. Build an accessible modal with focus trap and Escape to close.
2. Add enter/exit animations to a dropdown menu.
3. Virtualize a list of 10,000 rows with react-window.
4. Run a Lighthouse accessibility audit and fix the issues.
5. Respect prefers-reduced-motion in your animations.

const MemoChild = React.memo(function Child({ value, onClick }) {
  return <button onClick={onClick}>{value}</button>;
});

function Parent({ data, id }) {
  const handleClick = useCallback(() => doSomething(id), [id]);
  const result = useMemo(() => expensiveCalc(data), [data]);

  return <MemoChild value={result} onClick={handleClick} />;
}

• Faster, smoother UIs: Less wasted work.
• Smaller initial bundle: Code splitting loads only what's needed.
• Usable large lists: Virtualisation keeps FPS high.
• Profiler shows targets: Precise optimisation, not guesses.
• Better mobile performance: Lower CPU and memory.

• Premature optimisation: Makes code harder to read.
• Overusing memoisation: Costs memory and CPU.
• Wrong dependency arrays: Cause bugs and stale values.
• Complexity for little gain: In small apps, optimisations rarely matter.
• Extra code: More places to keep in sync.

• Measure first: Use Profiler, do not guess.
• Memoize only when measurable: If renders are cheap, don't bother.
• Split at route boundaries: Default code splitting strategy.
• Keep state close: Colocation reduces re-render scope.
• Shallow trees: Less work per render pass.

Profile app → identify slow component
        │
        ▼
Is it re-rendering too often? ── yes → React.memo / useCallback
        │
        no
        ▼
Is a computation heavy? ──────── yes → useMemo
        │
        no
        ▼
Is the bundle too large? ─────── yes → React.lazy + code splitting
        │
        no
        ▼
Is the list huge? ────────────── yes → virtualization
        │
        no
        ▼
Re-profile and verify improvement

1. Build a list of 1,000 items and profile it.
2. Add React.memo to a row component and measure the improvement.
3. Add route-level code splitting with React.lazy.
4. Virtualize the list and compare memory and FPS.
5. Use useTransition for a slow search filter.

import { render, screen, fireEvent } from '@testing-library/react';
import LikeButton from './LikeButton';

test('increments count on click', () => {
  render(<LikeButton />);

  expect(screen.getByText(/Likes: 0/)).toBeInTheDocument();
  fireEvent.click(screen.getByRole('button'));
  expect(screen.getByText(/Likes: 1/)).toBeInTheDocument();
});

test('renders custom initial label', () => {
  render(<LikeButton label="Hearts" />);
  expect(screen.getByText(/Hearts: 0/)).toBeInTheDocument();
});

• Confidence when refactoring: Tests catch regressions.
• Faster feedback: Than manual QA.
• Living documentation: Tests describe expected behaviour.
• E2E catches real bugs: Integration issues surface in browsers.
• Better design: Testable code tends to be well-structured.

• Setup cost: Tooling, mocks, and CI take time.
• Brittle tests: Slow the team down.
• Implementation details: Testing them causes false failures.
• E2E slow and flaky: Hard to maintain at scale.
• Over-testing: 100% coverage is not the goal.

• Test behaviour, not implementation: User-facing outcomes.
• Query the DOM like a user: roles, labels, text.
• Mock at the network layer: MSW gives realistic tests.
• Follow the testing pyramid: Many unit, some integration, few E2E.
• Fast feedback loops: Keep tests under a few seconds when possible.

         ▲        Few E2E tests (Cypress/Playwright)
        ╱ ╲
       ╱   ╲      Some integration tests (RTL)
      ╱─────╲
     ╱       ╲    Many unit tests (Jest/Vitest)
    ╱─────────╲

MSW flow:

  Component → fetch('/api/users')
                    │
                    ▼
             MSW intercepts
                    │
                    ▼
             Returns mock JSON
                    │
                    ▼
             Component renders data

1. Write a unit test for a utility function.
2. Write a component test for a form with validation.
3. Mock an API with MSW and test the loading → success flow.
4. Write one Cypress test for the login flow.
5. Add a Jest test for a custom hook using renderHook.

// app/users/page.tsx (Server Component by default)
async function UserList() {
  const users = await db.user.findMany(); // runs on server
  return (
    <ul>
      {users.map(u => <li key={u.id}>{u.name}</li>)}
    </ul>
  );
}

export default UserList;

• Faster first paint: Users see content quickly.
• Better SEO: Crawlers see full HTML.
• Smaller client bundles: RSC keeps data fetching on the server.
• TypeScript: Catches errors at compile time.
• Concurrent features: Keep the UI responsive.

• More moving parts: Server, client, hydration all interact.
• Hydration mismatches: Hard to debug.
• Framework required: RSC needs Next.js or similar.
• TypeScript setup: Extra tooling and learning curve.
• Caching complexity: SSR requires careful cache strategy.

• RSC is not a client feature: Needs a supporting bundler.
• Hydration must match server HTML: Small differences cause bugs.
• TypeScript plays well with React: Props, state, hooks all typed.
• Concurrent rendering: Allows interruptible updates.
• Streaming: Suspense boundaries stream HTML in chunks.

Browser request
      │
      ▼
Server renders HTML + data
      │
      ▼
HTML sent to browser (visible fast)
      │
      ▼
JS bundle downloaded
      │
      ▼
React hydrates HTML → interactive
      │
      ▼
Subsequent navigation is client-side

RSC boundary:

  Server Component (no JS shipped)
       │
       ▼
  Client Component (interactive)
       │
       ▼
  Server Component inside (again no JS)

1. Create a Next.js app and add one Server Component.
2. Compare the initial HTML of a CSR page and an SSR page.
3. Convert a small component to TypeScript with props types.
4. Use useTransition for a slow search filter.
5. Explain the difference between SSG and ISR with an example.

src/
├── features/
│   ├── auth/
│   │   ├── components/
│   │   │   ├── LoginForm.tsx
│   │   │   └── SignupForm.tsx
│   │   ├── hooks/
│   │   │   └── useAuth.ts
│   │   ├── api.ts
│   │   └── index.ts
│   └── todos/
│       ├── components/
│       ├── hooks/
│       └── api.ts
├── components/      # shared UI (Button, Modal)
├── hooks/           # shared hooks
├── lib/             # utilities
├── pages/ or app/   # routing entry points
└── App.tsx

• Predictable structure: New devs onboard faster.
• Smaller blast radius: Changes stay inside features.
• Consistent UI: Design system keeps look and feel uniform.
• Automated quality gates: Catch issues before code review.
• Better collaboration: Conventions reduce friction.

• Setup effort: Tooling and Storybook take time.
• Rigid conventions: Can slow prototyping.
• Design system maintenance: Requires ongoing care.
• Too many shared components: Cause coupling.
• Overhead for small teams: Process can feel heavy.

• Feature folders own their stuff: Components, hooks, API calls together.
• Shared components are minimal: Generic and reusable.
• Public APIs via index.ts: Barrel exports.
• Consistent naming: PascalCase components, camelCase hooks.
• TypeScript everywhere: Types catch bugs early.
• Environment separation: .env.development, .env.production.

┌──────────────────────────────────┐
│  app/  (routing, providers)      │
├──────────────────────────────────┤
│  features/  (auth, todos, cart)  │
├──────────────────────────────────┤
│  components/  (Button, Modal)    │
├──────────────────────────────────┤
│  hooks/  lib/  (shared logic)    │
├──────────────────────────────────┤
│  services/ api/  (network)       │
└──────────────────────────────────┘

Dependency rule: outer layers import
from inner layers, not the reverse.

1. Refactor a small app into a feature-based folder structure.
2. Create three shared components and document them in Storybook.
3. Set up ESLint + Prettier + TypeScript in a Vite React project.
4. Add a pre-commit hook with Husky and lint-staged.
5. Write a short README explaining your folder structure.

✔ Auth (login / signup)
✔ REST or GraphQL API
✔ Global state (Redux Toolkit / Zustand)
✔ Server state (TanStack Query)
✔ Routing + protected routes
✔ Forms with validation
✔ Responsive UI (Tailwind / CSS Modules)
✔ Accessibility (keyboard, ARIA)
✔ Tests (Jest + RTL, one Cypress flow)
✔ CI/CD + deployment (Vercel / Netlify)
✔ README with screenshots and live link

• Real understanding: Building teaches more than watching.
• Portfolio: Projects impress employers and clients.
• Bug exposure: You learn to debug real problems.
• Architectural sense: Combining features reveals trade-offs.
• Confidence: Shipping something real changes how you see yourself.

• Time-consuming: Real projects take weeks.
• Overwhelming at first: The empty repo can freeze beginners.
• Scope creep: Features grow beyond the plan.
• Deployment friction: Env vars, DNS, and CI/CD add work.
• Unfinished projects: Without focus, many stay half-done.

• Start small, ship early: Iterate instead of over-planning.
• One strong capstone beats five unfinished projects.
• Write a README: Screenshots, features, tech stack, live link.
• Deploy from day one: Practice the full loop.
• Test the critical paths: Login, checkout, submit.
• Keep a changelog: Show progress and thought process.

Beginner  ──► Todo / Weather / Quiz
        │
        ▼
Intermediate ──► Movie search / Blog / Expense tracker
        │
        ▼
Advanced  ──► E-commerce / Chat / Admin dashboard
        │
        ▼
Capstone  ──► Full-stack + Auth + Tests + CI/CD + Deploy

Suggested timeline for a capstone:

  Week 1: Setup + Auth + basic routing
  Week 2: Core features + API integration
  Week 3: Polish UI + tests + accessibility
  Week 4: Deploy + README + demo video

1. Build a Todo app with localStorage persistence.
2. Build a Movie search app using a public API and TanStack Query.
3. Build an Expense tracker with charts and Zustand.
4. Build a capstone: full-stack app with auth, API, tests, and deployment.
5. Write a README with screenshots and a live link.
6. Record a short demo video and post it on your portfolio.