A Working Theory Of Components
summary
A practical theory claims a component must be easy to reason about, context-agnostic, and independent and isolated; a concrete checklist (in contributing docs) spells out written design and usage docs, unit and visual tests, limited variants, imported JS and styles, single namespace, and accessible defaults. Examples cover PHP, Sass, plain CSS, React, NPM, webpack, styled-components and functional CSS. The checklist verifies components in isolation and at scale so libraries actually work across browsers, inputs, and RTL.
AI-written summary · about
chapters (21)
- 0:00Elyse
- 2:58constant iteration
- 3:39the tools we have today didn't exist 10 years ago
- 4:19changing the way we conceptualize our work
- 6:52Vulcan fit the understanding of the world
- 7:08how do we design and code for the modern web?
- 7:56working towards the same core idea
- 8:40how can we test our theory?
- 8:52a component must be
- 9:10easy to reason about
- 11:02context agnostic
- 12:56independent and isolated
- 14:57a theory of the world of modern web development
- 16:02finding new answers strengthens the theory
- 16:58applying the
- 17:17component checklist
- 18:48independent & isolated
- 19:17we keep the theory close at hand
- 20:40an experimental quest
- 22:01when black holes collide, they make a sound
- 22:57beyond today's understanding
related talks
40m“A Working Theory of Components”
23mA Philosophy for Designing Components with Composition
24mFrom Sketch to Code Designing a Component Kit
40mCommon Component Decomposition Pitfalls (And How To Avoid Them!)
44mWriting good components
26mComponents, Patterns and sh*t it’s Hard to Deal with
24mDesigning Component API
26mComponents, Patterns and Other Not-So-Simple Things to Manage