Overview

This page is the spaced-repetition companion to the Advanced Frontend course: five fixed sections that force active recall instead of passive re-reading. Work through them in order -- the Drills Overview frames the method, the Drill List is the recall Q&A plus applied problems plus hands-on code katas, Difficulty Progression explains how the drills ramp, Evaluation Criteria is the self-check checklist that confirms real automaticity, and Capstone Integration ties every drill back to the capstone steps. Every answer is hidden in a <details> block; try each item yourself before opening it.

Drills Overview

The drills exist to move a concept from "recognized when read" to "recallable when asked." Three formats, each attacking a different failure mode:

• Recall Q&A -- one short-answer question per concept (co-01 through co-37). Answer from memory, then check. If you cannot phrase it, the concept is not yet yours.
• Applied problems -- a scenario with the concept unnamed; you name the mechanism that solves it. This tests transfer, not recitation.
• Code katas -- a genuinely-executed before script that misapplies a concept, a diagnosed bug from the observed output, a fix from memory, then the after script and its output to compare.

The drills deliberately span this topic's cross-cutting big ideas -- taming-state (the cache/split and global-store drills) and consistency-latency-throughput (the Core Web Vitals and rendering- strategy drills) -- so you rehearse the reasoning, not just the vocabulary.

Drill List

Recall Q&A

Thirty-seven short-answer questions, one per concept (co-01 through co-37). Answer from memory, then check.

Q1 (co-01 -- rendering-csr). What is in the DOM before the JavaScript bundle runs under CSR, and why does that matter for crawlers?

Q2 (co-02 -- rendering-ssr). What does the server return per request under SSR, and what does it cost versus SSG?

Q3 (co-03 -- rendering-ssg). When is a page rendered under SSG, and what is the trade-off?

Q4 (co-04 -- streaming-ssr). What streams first under streaming SSR, and what problem does that solve?

Q5 (co-05 -- hydration). What does hydrateRoot do that mounting from scratch does not, and what happens on a server/client mismatch?

Q6 (co-06 -- islands-architecture). In an islands page, which regions ship JavaScript?

Q7 (co-07 -- react-server-components). Is 'use client' a render-tree boundary or a module-tree boundary, and can a client component render a server component?

Q8 (co-08 -- core-web-vitals). Name the current Core Web Vitals triad, and which one replaced FID, and when.

Q9 (co-09 -- lcp). What does LCP measure, what is the "good" threshold, and what does the reported element tell you?

Q10 (co-10 -- inp). What does INP measure, what is the "good" threshold, and why did it replace FID?

Q11 (co-11 -- cls). What does CLS measure, what is the "good" threshold, and the usual fix?

Q12 (co-12 -- critical-rendering-path). Why is CSS render-blocking, and what does that imply for first paint?

Q13 (co-13 -- code-splitting). What do React.lazy + <Suspense> do, and where must lazy be called?

Q14 (co-14 -- tree-shaking). What is tree shaking, and what makes it possible?

Q15 (co-15 -- client-vs-server-state). Why keep client UI state and the server cache separate, and what are invalidation and optimistic updates for?

Q16 (co-16 -- when-redux). When should you reach for a Redux-style global store?

Q17 (co-17 -- rules-of-hooks). State the two Rules of Hooks.

Q18 (co-18 -- useeffect-semantics). When do effects run relative to paint, when does cleanup run, and what gates a re-run?

Q19 (co-19 -- usememo-usecallback). What do useMemo and useCallback cache, and when should you actually use them?

Q20 (co-20 -- reconciliation-keys). Why do list items need stable keys, and what breaks with random keys?

Q21 (co-21 -- virtual-dom). What does the virtual-DOM diff emit, and why?

Q22 (co-22 -- signals-fine-grained). What re-runs when a signal changes, and how is that different from React?

Q23 (co-23 -- wcag-accessibility). What do semantic landmark elements give you for free, and what are live regions for?

Q24 (co-24 -- focus-management). Name two strategies for keyboard navigation in a composite widget, and what a focus trap does.

Q25 (co-25 -- controlled-vs-uncontrolled). What makes an input controlled vs uncontrolled, and what is forbidden?

Q26 (co-26 -- accessible-forms). Which three attributes wire an error to its input, and what does an error summary do?

Q27 (co-27 -- performance-budget). What does a performance budget turn bundle size into, and what follows a budget failure?

Q28 (co-28 -- http-caching-swr). What does stale-while-revalidate do?

Q29 (co-29 -- css-at-scale). How do CSS Modules and Tailwind each solve CSS's global-namespace problem, and what decides a specificity conflict?

Q30 (co-30 -- data-fetching-patterns). Why is a request waterfall slow, and what triggers a Suspense fallback (and what does not)?

Q31 (co-31 -- image-optimization). Name three image optimizations and what each controls.

Q32 (co-32 -- edge-rendering). What is the edge runtime, and what is its main constraint?

Q33 (co-33 -- typescript-frontend). How does a discriminated union plus a never-assertion improve correctness?

Q34 (co-34 -- pwa-service-worker). What three PWA capabilities make a site resilient and installable?

Q35 (co-35 -- i18n). Why use Intl and logical CSS properties for i18n?

Q36 (co-36 -- testing-behaviour). Why query by role/text rather than by class, and what is a Playwright smoke for?

Q37 (co-37 -- error-boundary). What does an error boundary catch, and what does it NOT catch?

Applied problems

Eight scenarios. Each describes a task without naming the construct -- decide which mechanism solves it, then check.

AP1. A product list reorders when the user sorts, and the checkbox a user just toggled silently un-toggles because state followed the wrong row.

AP2. An effect that logs the current filter keeps logging the initial value forever.

AP3. An "add to cart" shows the item instantly, but when the server rejects it the item stays in the cart.

AP4. A late-loading hero image shoves the headline down when it arrives, and Lighthouse reports a poor CLS.

AP5. A page feels slow; the dev added a Suspense boundary around an effect-fetching component but no fallback ever shows.

AP6. A teammate added a new "timeout" status to the state union and the UI silently renders blank for it.

AP7. A user in Germany sees prices as "1,234.56" with a comma decimal, which reads as two numbers.

AP8. Three sequential awaits make a dashboard take 300ms to load when each call is only ~100ms.

Code katas

Six hands-on repetition drills against small, self-contained, genuinely-executed TypeScript files -- pure standard library, no dependency. Each is a before/after example.ts colocated under drilling/code/. Run the before script, diagnose the bug from the observed output, fix it from memory, then compare against the after script and the shown output.

Kata 1 -- unstable list key (co-20)

The before version keys a list by the array INDEX, so a per-item draft attaches to a slot, not an item -- on reorder the draft lands on the wrong row.

Before (drilling/code/kata-01-unstable-list-key/before/example.ts)

// Kata 1 (before): a list rendered with INDEX keys loses per-item state on reorder.
interface Item {
  id: string;
  label: string;
}
 
function renderByKey(items: Item[], drafts: Map<string, string>): string[] {
  // THE BUG: key = String(index) -> the draft is tied to the slot, not the item
  return items.map((item, index) => {
    const key = String(index);
    return `${item.label}="${drafts.get(key) ?? ""}"`;
  });
}
 
const drafts = new Map<string, string>([["0", "typed-in-first"]]);
const before: Item[] = [
  { id: "a", label: "A" },
  { id: "b", label: "B" },
  { id: "c", label: "C" },
];
const reordered: Item[] = [
  { id: "b", label: "B" },
  { id: "a", label: "A" },
  { id: "c", label: "C" },
];
 
console.log("before reorder:", renderByKey(before, drafts));
console.log("after reorder: ", renderByKey(reordered, drafts));

Observed (buggy) output:

before reorder: [ 'A="typed-in-first"', 'B=""', 'C=""' ]
after reorder:  [ 'B="typed-in-first"', 'A=""', 'C=""' ]

// THE FIX: key = item.id -> the draft follows the ITEM when it moves.
function renderByKey(items: Item[], drafts: Map<string, string>): string[] {
  return items.map((item) => {
    const key = item.id; // stable identity key
    return `${item.label}="${drafts.get(key) ?? ""}"`;
  });
}
// drafts keyed by [["a", "typed-in-first"]] instead of [["0", ...]]

before reorder: [ 'A="typed-in-first"', 'B=""', 'C=""' ]
after reorder:  [ 'B=""', 'A="typed-in-first"', 'C=""' ]

Kata 2 -- useEffect stale dependency (co-18)

The before version has an empty dependency array, so the effect closes over the FIRST render's filter forever.

Observed (buggy) output:

effect logged (BUG: only first render): [ 'a' ]

// THE FIX: deps = [filter] -> the effect re-runs when filter changes.
prevDeps = runEffect(() => loggedFilters.push(filter), prevDeps, [filter]);

effect logged (FIX: every change): [ 'a', 'ab', 'abc' ]

Kata 3 -- no optimistic rollback (co-15)

The before version applies the optimistic add but keeps no snapshot, so a failed mutation cannot restore the prior state -- the row stays (a lie).

Observed (buggy) output:

after a FAILED add (BUG: row left behind): [ 'buy milk', 'fly kite' ]

// THE FIX: snapshot the prior state; restore it on failure.
const snapshot = [...list];
list = [...list, label]; // optimistic
if (fails) list = snapshot; // rollback

after a FAILED add (FIX: rolled back): [ 'buy milk' ]

Kata 4 -- CLS with no reserved space (co-11)

The before version renders an image with no reserved height, so when it loads it shoves content down -- a poor CLS.

Observed (buggy) output:

layout shift (px, BUG: huge): 300
CLS verdict: poor

// THE FIX: reserve the box (reservedHeight = intrinsicHeight) so the layout is stable.
const fixedImage: ImageBox = { reservedHeight: 300, intrinsicHeight: 300 };

layout shift (px, FIX: zero): 0
CLS verdict: good

Kata 5 -- controlled input mode switch (co-25)

The before version clears the field by setting value = undefined, which flips the input from controlled to uncontrolled mid-life.

Observed (buggy) output:

modes: controlled -> uncontrolled
warnings: [ 'Warning: changing controlled to uncontrolled. Inputs should not switch modes.' ]

// THE FIX: clear with "" (not undefined) so value is always a string -> always controlled.
const modes = [inputMode("hi"), inputMode("")];

modes: controlled -> controlled
warnings: []

Kata 6 -- non-exhaustive switch (co-33)

The before version handles three of four state variants; the unhandled "stale" falls through to a silent empty-string default.

Observed (buggy) output:

render stale (BUG: empty): ""

// THE FIX: add the "stale" case AND a never-assertion so a future missing case is a compile error.
case "stale":
  return "Stale -- refetching";
default: {
  const exhaustive: never = state; // exhaustiveness check
  return exhaustive;
}

render stale (FIX: handled): Stale -- refetching

Difficulty Progression

The drills ramp in three tiers, matching the course's own Beginner/Intermediate/Advanced structure:

• Recall first (the Q&A) -- pure retrieval, no application. If recall fails, re-read the cited example before moving on. These map 1:1 to co-01 through co-37 in concept order.
• Applied second (the problems) -- the concept is unnamed; you must recognize the mechanism from a real-world symptom. This tests transfer: the same idea phrased as a bug report rather than a definition.
• Katas last (the code) -- a genuinely-executed buggy script whose OUTPUT is the evidence. You diagnose from the output, fix from memory, then compare. This is the closest to real debugging.

Work top-to-bottom within each tier and do not open a <details> block until you have committed to an answer. A drill you can only answer with the block open is a drill to revisit tomorrow.

Evaluation Criteria

Confirm each item without checking the manual first. If you hesitate, that concept needs another pass.

• I can name the four rendering strategies and the defining cost of CSR (co-01..co-04).
• I can explain what hydrateRoot does and what a mismatch warning means (co-05).
• I can explain why islands ship less JS than CSR (co-06).
• I can state whether 'use client' is a render-tree or module-tree boundary (co-07).
• I can name the LCP/INP/CLS triad and that INP replaced FID (co-08).
• I can state the good thresholds for LCP, INP, and CLS (co-09..co-11).
• I can explain why CSS is render-blocking for first paint (co-12).
• I can split code with React.lazy + <Suspense> and per route (co-13).
• I can explain what tree shaking drops and why (co-14).
• I can keep client UI state separate from the server cache, with invalidation and rollback (co-15).
• I can state when a Redux-style store is justified (co-16).
• I can state both Rules of Hooks (co-17).
• I can describe effect timing, cleanup, and dependency gating (co-18).
• I can use useMemo/useCallback as targeted optimizations (co-19).
• I can explain why stable keys matter and what random keys break (co-20).
• I can describe what the virtual-DOM diff emits (co-21).
• I can contrast signal fine-grained updates with a React re-render (co-22).
• I can name landmark roles and what live regions do (co-23).
• I can implement roving tabindex and a focus trap (co-24).
• I can distinguish controlled from uncontrolled and state the no-switch rule (co-25).
• I can wire an error to an input accessibly and build an error summary (co-26).
• I can enforce a performance budget as a CI gate (co-27).
• I can explain stale-while-revalidate (co-28).
• I can contrast CSS Modules, Tailwind, and the specificity model (co-29).
• I can avoid a fetch waterfall and state what triggers Suspense (co-30).
• I can apply srcset, lazy loading, and reserved dimensions to images (co-31).
• I can opt into the edge runtime and name its constraint (co-32).
• I can model state as a discriminated union and enforce exhaustive narrowing (co-33).
• I can build an app shell, installability, and an offline fallback (co-34).
• I can format with Intl, externalize messages, and handle RTL (co-35).
• I can query by behaviour, write a user-event flow, and a Playwright smoke (co-36).
• I can catch a render error with an error boundary, and name what it does NOT catch (co-37).

Capstone Integration

Every drill maps to a capstone step, so the recall rehearsed here is the recall the capstone depends on:

• Capstone Step 1 (SSR + baseline) rehearses co-04 (streaming SSR) and co-30 (paginated fetch). Drill Q4, Q30, and AP8 are the retrieval that step leans on.
• Capstone Step 2 (perf work + CWV) rehearses co-08, co-11, and co-27. Drill Q8-Q12, Q27, and Kata 4 are the retrieval; the capstone's measureCwv/rate are exactly Example 13's bands.
• Capstone Step 3 (cache + optimistic + derived) rehearses co-15 and co-19. Drill Q15, Q19, AP3, and Kata 3 are the retrieval; the capstone's optimisticAdd is Example 34 and selectFiltered is Example 36.
• Capstone Step 4 (ARIA widget + tests) rehearses co-23, co-24, and co-36. Drill Q23, Q24, Q36, and Kata 1 are the retrieval; the combobox + arrow-key nav are Examples 44-45, and the tests are Examples 76-78.

If a capstone step feels shaky, return to its mapped drills before re-attempting it -- the capstone is the integration test of exactly these concepts.

← Previous: Capstone