Let's Use Modifier.Node
summary
Explains why Modifier.Node replaces Modifier.composed: composed causes excessive recompositions and bloated Composition (example showed a simple clickable creating 34 remembers and 11 side‑effect composables). Describes Compose v1.3.0’s approach of splitting modifier state into a persistent node chain and a transient element chain, and walks through the Modifier.Node API (onAttach/onDetach/isAttached, create/update, equals/hashCode), migration steps, recommended code patterns for remember, CompositionLocal, disposableEffect/launchEffect, and a concrete TabIndicatorOffset Node implementation used in the DroidKaigi app.
AI-written summary · about
chapters (15)
- 0:00Modifier.Node intro
- 1:25Performance in Modifier.composed
- 3:31Previous Modifier problems
- 5:17Modifier.composed issues
- 8:28Need for Modifier.Node
- 9:31Modifier.Node explained
- 10:35Modifier.Node lifecycle
- 11:57Modifier.Element vs Node
- 14:24Migrating to Modifier.Node
- 15:28Implementing Modifier.Node classes
- 17:14Modifier.Element details
- 18:15Rewriting Compose to Modifier.Node
- 21:54Complex Modifier.Node functions
- 23:41TabIndicatorOffset migration
- 29:43Q&A
related talks
21mCompose Modifiers deep dive
37mUnderstanding Compose modifiers and how their order affects UI
37m5 Easy steps to build a Compose API
38mComprehensive Guide to Jetpack Compose Modifiers
42mCompose: Beyond Android development
28mCompose at Scale: Stop Unnecessary Recomposition
38mDesigning scalable Compose APIs
36mNever Be Confused Again! A Practical Guide to Writing Jetpack Compose