Composing an API the *right* way
summary
Google's Compose guidelines condense ~13,000 words and recommend concrete rules: composable functions either emit UI (use UpperCamelCase nouns) or return values (lowercase); components emit a single root node and return Unit; accept a modifier as first optional parameter and apply it to the root; order parameters as required, modifier, then trailing content slot; avoid exposing MutableState — pass plain values plus callbacks or a state holder with a factory; use slot APIs and movableContentOf to avoid unnecessary recomposition; use KtLint/Detekt rules from the Compose rules fork.
AI-written summary · about
chapters (16)
- 0:00Introduction to API design
- 1:50Google’s Compose API guidelines
- 3:56Naming conventions in Compose
- 8:17Components and single root nodes
- 11:04Stateful vs stateless components
- 13:51Composition locals vs parameters
- 15:35Default arguments and null values
- 17:39Grouping default values
- 19:24Modifiers in Compose
- 21:11Modifier parameter best practices
- 25:01Slot APIs and content passing
- 28:11Movable content optimization
- 30:19Parameter ordering rules
- 33:09Handling state in components
- 36:19State holders and simplification
- 39:09Tools and resources summary
related talks
39mComposing an API the *right* way
36mComposing an API the *right* way
37m5 Easy steps to build a Compose API
28mUnlocking Seamless Collaboration: Design-First APIs for Components
25mEverything is an API
01h 36mThe Most Important API Design Guideline - No, It's Not That One
27mAPI Design Through the Lens of Photography
49mLet's make a contract: the art of designing a Java API