React Components
Components are the unit of reuse. Get the abstraction boundary wrong and you carry the cost in every file that imports it.
Aim to use Component Driven Development — build components in isolation, compose in context.
Five Dimensions
| Dimension | Question |
|---|---|
| Structure | How does it compose? |
| Aesthetics | Does it follow the design system? |
| Variance | How many states does it handle? |
| Words | Does the copy do the work? |
| Motion | Does animation serve function? |
Dig Deeper
- Hooks — State, effects, refs, memoization — React's core primitives
- Concepts — Server components, motion, animation patterns
- Libraries — shadcn, dApp dev kits, component ecosystems
- Feature Components — Maps, charts, calendars, tables, SVGs
- Browser APIs — Web platform capabilities beyond React
- Browser Maps APIs — Map library selection and integration
Links
- Uncontrolled vs Controlled — A matter of perspective
- Words — Jason Fried on naming
- SVGR — Turn SVGs into React components
- next markdown — Markdown rendering
- pdfme — PDF generation
- TailwindPDF — PDF styling with Tailwind
Context
- Component Driven Development — The methodology behind isolation-first
- Tailwind CSS — Design system distribution
- Engineering Best Practices — Quality gates that prevent rework
- Anti-Patterns — Architecture violations to avoid
- Product Design — Design checklists with pass/fail thresholds
Questions
When does a component earn its own abstraction versus staying inline?
- How do you decide between a headless component library and a styled one?
- What signals tell you a component is doing too much?
- When should a feature component live in a shared library versus the consuming app?