Composing an API the *right* way
summary
Summary of actionable rules from the AndroidX Compose guidelines and JetBrains Compose Multiplatform details: use camelCase for constant-like objects and nouns with uppercase for UI-emitting composables, distinguish emitter vs value-returning functions, make components return unit and emit exactly one root node, avoid returning or accepting mutable State — take plain values and callbacks instead, prefer explicit parameters over composition locals for non-global data, expose a Modifier default = Modifier as the first optional param and apply it to the root, collect many defaults into public objects, use slot APIs and movableContentOf to preserve content across branches, put the primary slot content last, and enforce rules with kotlin lint/detekt checks.
AI-written summary · about
chapters (17)
- 0:00API design in Compose
- 1:26Constants conventions in Compose
- 3:56Naming Composable functions
- 6:46Composable components
- 8:51Components return Unit
- 10:57Parameters vs CompositionLocals
- 13:03Default arguments
- 16:13Modifiers in Compose
- 18:21Modifier parameters
- 21:50Chaining Modifiers
- 23:15Slot APIs
- 26:24Slot content lifecycle
- 28:30Parameter ordering
- 31:45State handling
- 34:34Stakeholders for state
- 37:44Framework vs app code
- 38:27Tooling for Compose
related talks
36mComposing an API the *right* way
41mComposing an API the *right* way
37m5 Easy steps to build a Compose API
25mEverything is an API
49mLet's make a contract: the art of designing a Java API
27mModern Java API Design
41mWho Is That API For? Practical User‑Focused Techniques for Android Library Design
51mLet's make a contract: the art of designing a Java API