migrating-to-modifier-node

Create three pieces: a public extension function, a data class ModifierNodeElement implementing create() and update(), and a Modifier.Node subclass implementing the specialized interfaces your modifier needs. Move side effects into onAttach/onDetach and use the node's built-in coroutineScope.

Compose uses the Element's equals() to decide whether to call update() or leave the node alone. A plain class falls back to referential equality, so every apply looks like a new modifier and update() is never called, leaving the node with stale parameters.

Use DrawModifierNode and implement ContentDrawScope.draw(), calling drawContent() to render the wrapped content. It replaces drawBehind and drawWithCache for custom modifiers, and pairs with CompositionLocalConsumerModifierNode for theme-aware drawing.

Yes, every Modifier.Node exposes a built-in coroutineScope tied to its attach/detach lifecycle. Launch animations from onAttach() and never create your own CoroutineScope, which would leak past onDetach since the built-in one is cancelled automatically.

Skip migration when the modifier is a one-line composable wrapper, when built-in modifier composition already suffices, or when the real issue is a wrong-phase state read. Modifier.Node targets custom node behavior, not chain reordering.

Grep the module to confirm zero Modifier.composed usages remain, check the compiler report shows consuming composables as restartable and skippable, and confirm in Layout Inspector that recomposition counts plateau during modifier-driven animations on a release build.