Learnings from building a component library
summary
A four-person team runs a component library used by 300+ UI developers, enforces semantic versioning with weekly patch/minor releases, and keeps APIs stable by prefixing public symbols and marking internals with an underscore. Components default to onPush change detection, avoid direct DOM access, and use the Angular CDK and Angular Universal for platform independence. CI runs Axe accessibility checks, visual diffs on pull requests, custom lint rules, and a repo-scanner that finds deprecated usages across apps.
AI-written summary · about
chapters (13)
- 0:00Introduction and context
- 2:13Component library motivation
- 4:20API design philosophy
- 5:55Consistency and familiarity
- 7:49Building for flexibility
- 9:31Establishing developer contracts
- 12:06Versioning and communication
- 14:25Using the Angular CDK
- 15:25Managing change detection
- 17:30Platform independence
- 19:34Comprehensive testing
- 21:45Community and tooling
- 24:12Tracking usage and takeaways
related talks
29mBuilding an Angular component Library
44mBest Practices on building a UI component library for your company
25mFrom Design Systems to Component Libraries
24mCase Study: Creating a Component Library in React JS
34mBuilding component libraries using the Angular CDK
46mHow to Evolve a Component Library Without Breaking It
28mDesign Decisions for the Components Library
33mKickstarting a library of internal React components for multiple teams
