Frontend for leads

You will not be asked to build a UI. You will be asked to make architecture decisions about one, review frontend work credibly, and explain why the team's state management is a mess. The lead-level insight that unlocks most of these conversations: most state problems come from treating server data and UI state as the same thing. They have different lifecycles, different invalidation rules and different owners.

The other recurring test is whether you can be skeptical about micro-frontends without being ignorant of them. Independent deploy for independent teams at real scale is the legitimate case; everything else is usually a net cost.

What this chapter covers

• [todo] React reconciliation, walked through
• [todo] Keys, and why index-as-key breaks lists
• [todo] Hooks rules and the useEffect dependency traps
• [todo] Concurrent React: startTransition, useDeferredValue, Suspense
• [todo] Server Components and the "use client" boundary, worked
• [todo] The state ladder, and when to climb each rung
• [todo] Redux thunk vs saga vs observable
• [done] Migrating a Redux store to a server cache
• [todo] Rendering strategy matrix: CSR, SSR, SSG, ISR, streaming SSR
• [todo] Core Web Vitals, and an INP debugging transcript
• [todo] Micro-frontends and Module Federation: the skeptical case
• [todo] Frontend security: XSS, CSP with nonces, third-party script risk
• [todo] Accessibility as a design input, not a launch gate
• [todo] Testing ratio: unit, component, E2E, visual regression
• [todo] Streaming AI UIs: token rendering, thinking states, citations, undo

Source: §22.