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

• [done] React's rendering model covers reconciliation walked through, keys and why index-as-key breaks lists, and the hooks rules with the useEffect dependency traps
• [done] Concurrent React and Server Components covers startTransition, useDeferredValue, Suspense and streaming, plus Server Components and the "use client" boundary
• [done] The state ladder covers the six rungs and the thunk vs saga vs observable choice
• [done] The rendering strategy matrix covers CSR, SSR, SSG, ISR, streaming SSR and islands
• [done] Migrating a Redux store to a server cache
• [done] Diagnosing a bad INP
• [done] When micro-frontends are worth it
• [done] Frontend security covers XSS classes, nonce-based CSP with strict-dynamic, Trusted Types, and third-party script risk
• [done] Accessibility as a design input
• [done] The frontend testing ratio covers unit, component, E2E, visual regression and contract layers
• [done] Streaming AI UIs covers token rendering, thinking and tool states, citations, stopping and undo

Source: §22.