5 Easy steps to build a Compose API
summary
Existing modifier.swipeable forces recompositions because anchors live in composition; the team refactors it into a state-driven design: anchor dragable state plus a light modifier anchorDragable, moves the API from material into foundation, and exposes the internal updateAnchors function so layout-dependent anchors update without recomposition. Prototypes iterate from swipeable v2 to the final API, the modifier approach reduces cancellations and is now used by M3 modal bottom sheets, showing the new API works in real components.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:27The Swipeable API problem
- 5:20What is an API?
- 8:59Step one: Define the goal
- 13:18Naming APIs matters
- 17:12Building scalable APIs
- 20:41Layering APIs in Compose
- 23:55Choosing Compose components
- 28:54Prototyping and iterating
- 31:03Do you need this API?
- 34:13Collecting feedback
- 34:55Closing thoughts
related talks
32mBuilding Compose APIs
21mCompose Modifiers deep dive
38mDesigning scalable Compose APIs
07m5 quick animations to make your Compose app stand out
35mBuild adaptive apps with Compose's new APIs
32mLet's Use Modifier.Node
32mPractical Magic with Animations in Compose
39mRe-Compose your UI: building an atomic design library