Common Component Decomposition Pitfalls (And How To Avoid Them!)
summary
Argues that component decomposition succeeds when concrete choices are clear: use rule of three before abstracting, split a three‑step wizard into routable step components, refactor a large form into design‑system atoms, and prefer prefer duplication over the wrong abstraction until patterns repeat. Demonstrates tools and patterns: React examples, Material‑UI style primitives, Redux pitfalls, and use downshift for autocomplete to isolate behavior. Shows that these changes reduce file size, improve cohesion, and make UIs easier to test.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 0:57About Rob
- 2:39Take A Deep Breath
- 3:07What Are Components
- 4:24Component Decomposition
- 5:20Amazon Example
- 6:07Why is this process hard
- 8:13The Goldilocks Problem
- 9:42The Too Many Component Problem
- 11:02The List Component Problem
- 12:29The Form Component Problem
- 14:07The Bob Ross Problem
- 14:55Large Files
- 15:40Similar Components
- 17:08Multi Modal Components
- 18:12Example
- 20:24The Future
- 21:50Strategies
- 24:18Reusable Components
- 26:43Specific Components
- 28:31Specific Components Example
- 30:55Isolating Concerns
- 33:39Crossing Complexity Boundaries
- 37:36Conclusion
related talks
20mComponentization Patterns in React
30mAtomic Design: Breaking Up is Hard to Do
26mComponents, Patterns and Other Not-So-Simple Things to Manage
26mComponents, Patterns and sh*t it’s Hard to Deal with
24mDesigning Components for Fun, Profit and Sanity
35mAdvanced patterns in building React Components
30mComponents, patterns and sh.t it’s hard to deal with
32mUI Development Made Simple