Building Better Components
summary
Ember component patterns get named and demonstrated with concrete tradeoffs: data down actions up for reusable components that never mutate external state; single responsibility components that accept a model and mutate it directly for one-use forms; provider components that yield behavior and set tagName = '' to avoid wrapper divs; computed properties and Ember’s yield helper keep rendering declarative. Claim: readable components save time (Clean Code quote: reading vs writing over ten to one). Examples include a rewritten codebase that removes jQuery and giant “data fetcher” monsters.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:22THE DATA FETCHER
- 3:39Single Responsibility Principle
- 4:11Don't Repeat Yourself Principle
- 5:25Reusable Component Pattern
- 6:18Reusable Component: Date Picker
- 8:06Single Purpose Component Pattern
- 8:52Single Purpose Component: Edit User Form
- 10:09Reusable vs Single Purpose Components
- 11:18Provider Component Pattern
- 13:13Provider Component: Percentage Complete
- 14:23Presentational Component Pattern
- 14:47Presentational Component: Progress Bar
- 15:28Contextual Component Pattern
- 16:40Contextual Components: Modal
- 19:11Wishful Programming
- 20:03Writing the Interface
- 21:31Declarative vs Imperative Code
- 22:35Declarative Rendering
related talks
29mIdiomatic Ember, Sweet Spot of Performance and Productivity
30mMastering the Art of Forms
40mEmber's Technical Foundations – And How They Are Changing
33mInteroperable Component Patterns
26mEmber Components Transclude My Directives
27mDesigning for Ember Apps
36mCompose All the Things
31mThe {{x-foo}} in You