Migrating To Modifier Node

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 87cfb886f00d · 16 Oct 2026Report an issue or request a re-scan

• Publisherskydoves GitHub userOwner of the repository this skill is read from
• Source folderskydoves/compose-performance-skills/modifiers/migrating-to-modifier-nodeThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict87cfb886f00dA new audit runs when the source changes
• Repository statusNot archivedLast push 121 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use this skill to author new custom Jetpack Compose modifiers and migrate legacy ones from Modifier.composed { } to Modifier.Node + ModifierNodeElement<T>. Covers the persistent-node lifecycle (onAttach, onDetach,…

---
name: migrating-to-modifier-node
description: Use this skill to author new custom Jetpack Compose modifiers and migrate legacy ones from Modifier.composed { } to Modifier.Node + ModifierNodeElement<T>. Covers the persistent-node lifecycle (onAttach, onDetach, onReset, coroutineScope), the specialized node interfaces (DrawModifierNode, LayoutModifierNode, SemanticsModifierNode, PointerInputModifierNode, CompositionLocalConsumerModifierNode, LayoutAwareModifierNode, GlobalPositionAwareModifierNode, ObserverModifierNode, DelegatingNode, TraversableNode), why ModifierNodeElement MUST be a data class for diffing, and the manual-invalidation knobs (invalidateDraw, invalidateMeasurement, invalidatePlacement, shouldAutoInvalidate). Use when the developer mentions Modifier.composed, custom modifier, ModifierNodeElement, Modifier.Node, "rewriting our drawBehind helper", node lifecycle, or sees Modifier.composed { } in a code review.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - modifier-node
  - modifier-composed
  - custom-modifier
  - draw-modifier-node
  - layout-modifier-node
  - composition-local-consumer
---

# Migrating to Modifier.Node — Persistent Nodes Over `composed { }`

`Modifier.composed { }` allocates a fresh composable scope per modifier per composition: it cannot be skipped, cannot be hoisted, and forces the parent to run on every recomposition. `Modifier.Node` is a persistent node diffed by `ModifierNodeElement.equals()` — created once on first apply, updated in place on subsequent applies. There is **no per-recomposition allocation, no fresh composable scope, and no parent invalidation chain**, which is why Android Developers describes the system as "designed from the ground up to be far more performant" than the legacy `composed { }` factory (see `developer.android.com/develop/ui/compose/custom-modifiers`). This skill teaches Claude how to author new modifiers as `Modifier.Node` and migrate legacy `composed { }` factories.

## When to use this skill

- A custom modifier currently uses `Modifier.composed { }` (search the module for `Modifier.composed`).
- Authoring a new custom modifier from scratch — never start with `composed { }`.
- A code review surfaces a `composed { }` factory.
- The custom modifier needs a `CoroutineScope` (animation loop, debouncer), reads a `CompositionLocal`, participates in layout / drawing / pointer input, or tracks layout coordinates.
- A `@TraceRecomposition` log shows the parent composable recomposing on every frame because a `composed { }` modifier is in the chain.

## When NOT to use this skill

- The "modifier" is actually a one-line composable wrapper that can stay a `@Composable` function — leave it alone.
- The built-in modifier composition (`Modifier.padding(...).clickable(...)`) is sufficient, no custom node behavior needed.
- The fix the developer needs is reordering an existing chain, not authoring a new node — see `../ordering-modifier-chains/SKILL.md`.
- The custom modifier reads a hot animation value via `Modifier.composed { }` only to feed a value-form modifier underneath — the underlying issue is a wrong-phase state read; see `../../recomposition/deferring-state-reads/SKILL.md`.

## Prerequisites

- **Compose UI 1.5+** — `Modifier.Node` and the specialized node interfaces are stable here.
- **Kotlin 2.0+** with `org.jetbrains.kotlin.plugin.compose` applied. Strong Skipping is on by default; non-skippable modifiers compound at scroll velocity.
- A release build for any final measurement (skydoves hot take #5: debug builds run interpreted and lie).
- For the full per-interface override surface and lifecycle diagram, read `references/modifier-node-anatomy.md` before authoring anything beyond a `DrawModifierNode`.

## Workflow

- [ ] **1. Identify every `Modifier.composed { }` factory in the module.** Grep for `Modifier.composed`. Each match is one migration target. Note what the body does — `remember`, `drawBehind`, `LaunchedEffect`, a `CompositionLocal` read, a pointer handler — because that decides which specialized node interface(s) you need.

- [ ] **2. Sketch the three pieces every Modifier.Node migration produces.**
  - **(a) The public extension** — `fun Modifier.foo(...): Modifier = this then FooElement(...)`. Same name and signature as the old `composed { }` factory.
  - **(b) The `ModifierNodeElement<T>` `data class`** — holds the parameters; implements `create()` (called once on first apply) and `update(node: T)` (called on subsequent applies).
  - **(c) The `Modifier.Node` subclass** — holds mutable state (`var` fields), implements one or more specialized node interfaces, and runs lifecycle hooks (`onAttach`, `onDetach`, `onReset`).

- [ ] **3. Make the Element a `data class`.** The compiler-synthesized `equals()`/`hashCode()` are how Compose decides whether to call `update()` vs leave the node alone. **MUST** be `data class`. A plain `class` falls back to referential equality, the diff thinks every apply is a new modifier, and `update()` is never called — your node holds stale parameters silently.

- [ ] **4. Pick the right specialized node interface(s).** A `Modifier.Node` is empty by itself; behavior comes from interfaces it implements. The common ones:

| Interface | Use when the modifier needs to ... |
|---|---|
| `DrawModifierNode` | draw (replaces `drawBehind`/`drawWithCache`) |
| `LayoutModifierNode` | measure/place (replaces `layout { }` and custom `Layout`) |
| `SemanticsModifierNode` | contribute to accessibility |
| `PointerInputModifierNode` | handle pointer / gesture input (replaces `pointerInput`) |
| `CompositionLocalConsumerModifierNode` | read a `CompositionLocal` from inside the node |
| `LayoutAwareModifierNode` | get notified when this node's size/coordinates change |
| `GlobalPositionAwareModifierNode` | get notified about position in the window/root |
| `ObserverModifierNode` | observe arbitrary 

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/skydoves/compose-performance-skills
git -C compose-performance-skills checkout 87cfb886f00d

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 87cfb886f00d

Questions about Migrating To Modifier Node

• github.com/skydoves/compose-performance-skills/tree/main/modifie — the audited source at commit 87cfb886f00d and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology