The 80/20 Rule for Compose Modifiers: How to Unlock Faster UI with Modifier.Node

In our last discussion, we mastered the art of ordering standard modifiers for peak performance. We treated them as powerful, pre-built tools, like a perfect set of wrenches for any job. last discussion But what happens when those pre-built tools aren't enough? Every Android developer has hit that point: you're building a unique UI component, and the standard modifiers just don't cut it. Maybe you need a custom border that animates, a lifecycle-aware impression tracker for analytics, or a complex shimmer effect that reacts to a loading state. The problem is that simply nesting more Composables is often inefficient and breaks the modifier paradigm. This is where Modifier.Node comes in. It’s tied to the element tree’s lifecycle, not composition, so a single instance persists across recompositions. This means a single instance persists across recompositions, eliminating the overhead of repeated setup. Modifier.Node By the end of this deep dive you’ll leave with a copy-pasteable Quick Guide to Modifier.Node that you can use across your app. You’ll know when to choose Node over composed, how to wire factory → element → node, which Node interface to implement for drawing, layout, input, semantics, parent data, and global position, and how to keep state inside the node with surgical invalidation - no extra recompositions. The final FAQ gives you small, production-ready templates for each role so you can ship faster, with cleaner APIs and better performance. Modifier.Node composed factory → element → node Node interface inside the node surgical invalidation The Old Way: The composed Factory and Its Hidden Costs composed Before we dive into the elegance of Modifier.Node, let's understand what came before and why it wasn't sustainable at scale. Modifier.Node For years (well, although in case of Compose it sounds a bit exaggerated), Modifier.composed { ... } was our escape hatch for stateful modifiers: it let us call remember, LaunchedEffect, etc., right inside a modifier definition. It worked, but it tied modifier behavior to composition, not to the UI element’s real lifecycle. Modifier.composed { ... } stateful remember LaunchedEffect composition The core problem is that Modifier.composed is fundamentally at odds with Compose's optimization strategy. Here's why: Modifier.composed No real skipping, broken equality. The lambda behind composed can’t be cached the way a composable can, so the produced modifier practically never compares equal to its previous instance. Compose treats it as “changed,” so the chain re-runs and triggers unnecessary recompositions. remember gets pricey. Stateful modifiers built with composed lean on multiple remember calls. Because they recompose more often than they should, those remember checks/allocation paths stack up fast. Modifier-tree bloat. composed ended up everywhere. A “simple” Modifier.clickable can internally fan out to dozens of elements and remembers, shifting your UI from “a few layouts with light decoration” to deep modifier forests. Allocation & materialization churn. On each recomposition, ComposedModifier lambdas are re-materialized: new elements, new state holders, new owning objects on the layout node - lots of short-lived garbage and GC pressure for the same semantics. No real skipping, broken equality. The lambda behind composed can’t be cached the way a composable can, so the produced modifier practically never compares equal to its previous instance. Compose treats it as “changed,” so the chain re-runs and triggers unnecessary recompositions. No real skipping, broken equality. composed never compares equal unnecessary recompositions remember gets pricey. Stateful modifiers built with composed lean on multiple remember calls. Because they recompose more often than they should, those remember checks/allocation paths stack up fast. remember composed remember remember stack up fast Modifier-tree bloat. composed ended up everywhere. A “simple” Modifier.clickable can internally fan out to dozens of elements and remembers, shifting your UI from “a few layouts with light decoration” to deep modifier forests. Modifier-tree bloat. composed Modifier.clickable dozens of elements and remembers deep modifier forests Allocation & materialization churn. On each recomposition, ComposedModifier lambdas are re-materialized: new elements, new state holders, new owning objects on the layout node - lots of short-lived garbage and GC pressure for the same semantics. Allocation & materialization churn. ComposedModifier re-materialized short-lived garbage The Modern Solution: An Introduction to Modifier.Node Modifier.Node After seeing the hidden costs of the composed factory, it's clear we need a better tool - one designed from the ground up for performance, state management, and a clear lifecycle. That tool is Modifier.Node. It represents a fundamental shift in how we think about creating custom modifiers: we move away from shoehorning state into composable lambdas and towards creating real, lifecycle-aware objects. composed Modifier.Node What a Node actually is A persistent object, not a composable. A Modifier.Node instance is created once and survives recompositions. The lightweight ModifierNodeElement (your data holder) can be reallocated each recomposition, but it updates the same node via update(). Equality (equals/hashCode) on the element decides whether to update or replace. A persistent object, not a composable. Modifier.Node survives recompositions ModifierNodeElement updates the same node update() equals hashCode Modifier.Node gives you three crucial lifecycle hooks that were impossible with composed: Modifier.Node composed onAttach(): Your Setup Phase Called when your modifier becomes part of the active UI tree. This is where you initialize resources, start animations, or set up listeners: private class MyCustomNode : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Perfect place to start animations, initialize resources startShimmerAnimation() registerWithAnalytics() } } onDetach(): Your Cleanup Phase Called when your modifier is removed from the UI tree. Critical for preventing memory leaks: override fun onDetach() { // Clean up resources, stop animations, unregister listeners stopShimmerAnimation() unregisterFromAnalytics() } onReset(): The Recycling Hook This is more subtle but powerful. Called when the modifier is about to be reused in a different context (think RecyclerView recycling): override fun onReset() { // Reset state for recycling - advanced optimization hasLoggedImpression = false resetAnimationToStart() } onAttach(): Your Setup Phase Called when your modifier becomes part of the active UI tree. This is where you initialize resources, start animations, or set up listeners: private class MyCustomNode : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Perfect place to start animations, initialize resources startShimmerAnimation() registerWithAnalytics() } } onAttach(): Your Setup Phase Called when your modifier becomes part of the active UI tree. This is where you initialize resources, start animations, or set up listeners: onAttach() private class MyCustomNode : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Perfect place to start animations, initialize resources startShimmerAnimation() registerWithAnalytics() } } private class MyCustomNode : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Perfect place to start animations, initialize resources startShimmerAnimation() registerWithAnalytics() } } onDetach(): Your Cleanup Phase Called when your modifier is removed from the UI tree. Critical for preventing memory leaks: override fun onDetach() { // Clean up resources, stop animations, unregister listeners stopShimmerAnimation() unregisterFromAnalytics() } onDetach(): Your Cleanup Phase Called when your modifier is removed from the UI tree. Critical for preventing memory leaks: onDetach() override fun onDetach() { // Clean up resources, stop animations, unregister listeners stopShimmerAnimation() unregisterFromAnalytics() } override fun onDetach() { // Clean up resources, stop animations, unregister listeners stopShimmerAnimation() unregisterFromAnalytics() } onReset(): The Recycling Hook This is more subtle but powerful. Called when the modifier is about to be reused in a different context (think RecyclerView recycling): override fun onReset() { // Reset state for recycling - advanced optimization hasLoggedImpression = false resetAnimationToStart() } onReset(): The Recycling Hook This is more subtle but powerful. Called when the modifier is about to be reused in a different context (think RecyclerView recycling): onReset() override fun onReset() { // Reset state for recycling - advanced optimization hasLoggedImpression = false resetAnimationToStart() } override fun onReset() { // Reset state for recycling - advanced optimization hasLoggedImpression = false resetAnimationToStart() } Capabilities are opt-in The real power and clarity of the Modifier.Node system come from its use of interfaces. A base Modifier.Node doesn't actually do anything on its own. To give it capabilities - like drawing, measuring, or handling touch events - you implement specific interfaces. Modifier.Node Modifier.Node do You add behavior by implementing node roles and Compose wires each into the correct phase: DrawModifierNode → custom drawing via ContentDrawScope.draw(). LayoutModifierNode → custom measure/layout. PointerInputModifierNode → pointer/gesture handling. SemanticsModifierNode, ParentDataModifierNode, LayoutAwareModifierNode, GlobalPositionAwareModifierNode, etc., for accessibility, parent hints, and position callbacks. DrawModifierNode → custom drawing via ContentDrawScope.draw(). DrawModifierNode ContentDrawScope.draw() LayoutModifierNode → custom measure/layout. LayoutModifierNode PointerInputModifierNode → pointer/gesture handling. PointerInputModifierNode SemanticsModifierNode, ParentDataModifierNode, LayoutAwareModifierNode, GlobalPositionAwareModifierNode, etc., for accessibility, parent hints, and position callbacks. SemanticsModifierNode ParentDataModifierNode LayoutAwareModifierNode GlobalPositionAwareModifierNode When your element’s update() runs, Compose auto-invalidates the needed phases for you. For advanced cases you can opt out and call phase-specific invalidations yourself (e.g., invalidateDraw(), invalidateMeasurement(), invalidatePlacement(), invalidateSemantics()) to avoid unnecessary work. This is how you keep heavy modifiers razor-thin during scroll/animation. update() auto-invalidates opt out invalidateDraw() invalidateMeasurement() invalidatePlacement() invalidateSemantics() CompositionLocals & observation Nodes can read composition locals where they’re used (not where they were created) via currentValueOf(...). If you need automatic reactions outside a draw/measure/semantics scope, implement ObserverModifierNode and wrap reads with observeReads { ... } to get onObservedReadsChanged() callbacks - no stray recompositions required. where they’re used currentValueOf(...) ObserverModifierNode observeReads { ... } onObservedReadsChanged() By combining these concepts, you get a system that is both powerful and predictable. You create a simple class that holds state, hooks into a reliable lifecycle, and performs only the specific jobs you assign it. This is the foundation for building truly performant, reusable, and elegant UI behaviors in Jetpack Compose. Factory → Element → Node (the minimal skeleton) Creating custom modifier involves 3 key parts: The Factory Function: The public API that developers will use. The ModifierNodeElement: A lightweight data holder that describes our modifier. The Modifier.Node: The stateful worker that contains the actual logic. The Factory Function: The public API that developers will use. The Factory Function: The ModifierNodeElement: A lightweight data holder that describes our modifier. The ModifierNodeElement The Modifier.Node: The stateful worker that contains the actual logic. The Modifier.Node // 1) Public API - cheap, pure, chainable fun Modifier.myFancyEffect(color: Color) = this.then(MyFancyElement(color)) // 2) Element — ephemeral config; created each recomposition, *updates* the same Node private data class MyFancyElement(val color: Color) : ModifierNodeElement () { override fun create(): MyFancyNode = MyFancyNode(color) override fun update(node: MyFancyNode) { if (node.color != color) { node.color = color node.invalidateDraw() // tell Compose exactly which phase to refresh } } } // 3) Node — persistent behavior; survives recompositions private class MyFancyNode(var color: Color) : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Start work tied to the modifier’s lifecycle (e.g., launch animations via coroutineScope) } override fun onDetach() { // Clean up (cancel jobs, unregister callbacks, release resources) } // Role implementation: runs during the draw phase override fun ContentDrawScope.draw() { drawContent() // draw something using 'color' } } // 1) Public API - cheap, pure, chainable fun Modifier.myFancyEffect(color: Color) = this.then(MyFancyElement(color)) // 2) Element — ephemeral config; created each recomposition, *updates* the same Node private data class MyFancyElement(val color: Color) : ModifierNodeElement () { override fun create(): MyFancyNode = MyFancyNode(color) override fun update(node: MyFancyNode) { if (node.color != color) { node.color = color node.invalidateDraw() // tell Compose exactly which phase to refresh } } } // 3) Node — persistent behavior; survives recompositions private class MyFancyNode(var color: Color) : Modifier.Node(), DrawModifierNode { override fun onAttach() { // Start work tied to the modifier’s lifecycle (e.g., launch animations via coroutineScope) } override fun onDetach() { // Clean up (cancel jobs, unregister callbacks, release resources) } // Role implementation: runs during the draw phase override fun ContentDrawScope.draw() { drawContent() // draw something using 'color' } } Modifier.Node Field Manual: Best Practices & Anti-Patterns Let's walk through the essential do's and don'ts that separate a production-ready node from a problematic one. 1. State Management: Isolate and Own The primary performance benefit of Modifier.Node is that the node instance survives recomposition. This makes it the perfect place to hold state that shouldn't be tied to the composition lifecycle, like animation progress or transient user input. Modifier.Node survives recomposition Do: Keep State Inside the Node Do Treat your node as a stateful object. Store frequently changing values directly as properties on the node itself. Update them in the update method of your Element or in response to callbacks like onGloballyPositioned. update Element onGloballyPositioned Example: A node that tracks its own size Example: private class SizedNode : Modifier.Node(), LayoutModifierNode { // State is a simple property, owned by the Node. private var lastMeasuredSize: IntSize = IntSize.Zero override fun MeasureScope.measure( measurable: Measurable, constraints: Constraints ): MeasureResult { val placeable = measurable.measure(constraints) // Update the internal state during the layout pass this.lastMeasuredSize = IntSize(placeable.width, placeable.height) return layout(placeable.width, placeable.height) { placeable.placeRelative(0, 0) } } } private class SizedNode : Modifier.Node(), LayoutModifierNode { // State is a simple property, owned by the Node. private var lastMeasuredSize: IntSize = IntSize.Zero override fun MeasureScope.measure( measurable: Measurable, constraints: Constraints ): MeasureResult { val placeable = measurable.measure(constraints) // Update the internal state during the layout pass this.lastMeasuredSize = IntSize(placeable.width, placeable.height) return layout(placeable.width, placeable.height) { placeable.placeRelative(0, 0) } } } Why it's better: The composable that uses this modifier does not recompose when the size changes. The state is perfectly encapsulated within the layout phase, avoiding unnecessary composition work entirely. Why it's better: does not recompose Don't: Reading Composable State in Draw/Layout Logic Don't: Avoid passing lambdas into your Element that directly read state from the parent composable, especially for use in high-frequency callbacks like draw() or measure(). Element draw() measure() Example: Passing a State -reading lambda Example: State // In the composable val animatedColor by animateColorAsState(...) // Modifier.drawWithColor { animatedColor } // Color ) : Modifier.Node(), DrawModifierNode { override fun ContentDrawScope.draw() { drawContent() // Reading the external state here creates an implicit dependency // on the composition scope. drawRect(color = colorProvider()) } } // In the composable val animatedColor by animateColorAsState(...) // Modifier.drawWithColor { animatedColor } // Color ) : Modifier.Node(), DrawModifierNode { override fun ContentDrawScope.draw() { drawContent() // Reading the external state here creates an implicit dependency // on the composition scope. drawRect(color = colorProvider()) } } Why it's bad: While this might seem to work, it breaks the separation between composition and other phases. The colorProvider lambda is considered "unstable" by the Compose compiler because its captured value (animatedColor) changes. This can lead to the modifier being reallocated more often than necessary. The correct pattern is to pass the raw Color value into the Element and let the update function push the new value to the node. Why it's bad: colorProvider animatedColor Color Element update 2. Lifecycle & Coroutines: No Leaks Allowed Your node has a clear lifecycle: onAttach() and onDetach(). This is your contract for managing any resources, especially long-running jobs like animations or data listeners. onAttach() onDetach() Do: Scope Coroutines to the Node's Lifecycle Do: When you need to launch a coroutine, use the coroutineScope property available within Modifier.Node. This scope is automatically cancelled when the node is detached, preventing leaks. coroutineScope Modifier.Node Example: A node that starts an infinite animation Example: private class AnimatingNode : Modifier.Node(), DrawModifierNode { private val animatable = Animatable(0f) override fun onAttach() { // Use the node's own coroutineScope. // This job will be automatically cancelled onDetach. coroutineScope.launch { animatable.animateTo( targetValue = 1f, animationSpec = infiniteRepeatable(...) ) } } override fun ContentDrawScope.draw() { // ... use animatable.value to draw ... } } private class AnimatingNode : Modifier.Node(), DrawModifierNode { private val animatable = Animatable(0f) override fun onAttach() { // Use the node's own coroutineScope. // This job will be automatically cancelled onDetach. coroutineScope.launch { animatable.animateTo( targetValue = 1f, animationSpec = infiniteRepeatable(...) ) } } override fun ContentDrawScope.draw() { // ... use animatable.value to draw ... } } Why it's better: This is the canonical way to manage asynchronous work. It's safe, predictable, and guarantees that when your modifier leaves the screen, its background work stops with it. No manual job management needed. Why it's better: Don't: Fire-and-Forget Coroutines Don't: Never launch a coroutine from onAttach using a global scope (like GlobalScope) or a scope provided from the composition (like one from rememberCoroutineScope()) without manually managing its cancellation in onDetach(). onAttach GlobalScope rememberCoroutineScope() onDetach() Example: A classic memory and CPU leak Example: private class LeakyAnimatingNode( // Taking an external scope is a red flag private val externalScope: CoroutineScope ) : Modifier.Node(), DrawModifierNode { private val animatable = Animatable(0f) override fun onAttach() { // DANGER: This job is tied to an external lifecycle. // If externalScope lives longer than the node, this job // will run forever, even after the UI is gone. externalScope.launch { animatable.animateTo(...) } } // Missing onDetach logic to cancel the job! } private class LeakyAnimatingNode( // Taking an external scope is a red flag private val externalScope: CoroutineScope ) : Modifier.Node(), DrawModifierNode { private val animatable = Animatable(0f) override fun onAttach() { // DANGER: This job is tied to an external lifecycle. // If externalScope lives longer than the node, this job // will run forever, even after the UI is gone. externalScope.launch { animatable.animateTo(...) } } // Missing onDetach logic to cancel the job! } Why it's bad: This is a severe memory leak. If the externalScope outlives the node (which is very likely), you will have orphaned coroutines running in the background, consuming CPU and battery for UI that is no longer visible. Why it's bad: externalScope 3. Performance: Invalidate with Surgical Precision When your node's state changes, you need to tell Compose to re-run a specific phase (layout, draw, etc.). Modifier.Node gives you precise tools to do this. Using the wrong one can negate your performance gains. Modifier.Node Do: Invalidate Only What's Needed Do: If a state change only affects drawing, call invalidateDraw(). If it affects measurement, call invalidateMeasurement(). This queues the minimal amount of work required. invalidateDraw() invalidateMeasurement() Example: A node that redraws itself when a property changes Example: private class EfficientDrawNode(color: Color) : Modifier.Node(), DrawModifierNode { private var _color: Color = color var color: Color get() = _color set(value) { if (value != _color) { _color = value // We only need to redraw, not remeasure or recompose. invalidateDraw() } } override fun ContentDrawScope.draw() { // ... draw with _color ... } } private class EfficientDrawNode(color: Color) : Modifier.Node(), DrawModifierNode { private var _color: Color = color var color: Color get() = _color set(value) { if (value != _color) { _color = value // We only need to redraw, not remeasure or recompose. invalidateDraw() } } override fun ContentDrawScope.draw() { // ... draw with _color ... } } Why it's better: This is incredibly efficient. You are telling the system, "Hey, the size and position of this component are fine, just repaint it." This avoids expensive and unnecessary measure/layout passes for the entire subtree. Why it's better: Don't: Triggering Recomposition to Update the Node Don't: The whole point of Modifier.Node is to avoid recomposition. If you find yourself needing to change state in a parent composable just to trigger an update in your node, you're fighting the framework. Modifier.Node avoid Example: Using a MutableState to force an update. Example: MutableState // In the composable val redrawSignal = remember { mutableStateOf(0) } // MyModifier(redrawSignal.value) // Reading the state to force recomposition private class InefficientUpdateNode( private val redrawSignal: Int ) : Modifier.Node(), DrawModifierNode { // This node's state is being driven by recomposition, // which is what we want to avoid. } // In the composable val redrawSignal = remember { mutableStateOf(0) } // MyModifier(redrawSignal.value) // Reading the state to force recomposition private class InefficientUpdateNode( private val redrawSignal: Int ) : Modifier.Node(), DrawModifierNode { // This node's state is being driven by recomposition, // which is what we want to avoid. } Why it's bad: This completely defeats the purpose of using Modifier.Node. You've reintroduced a dependency on composition, forcing the parent and its children to be re-evaluated, when a simple call to invalidateDraw() or updating the node's properties via the Element.update method would have sufficed. Always push state down into the node; don't pull the node up with recomposition. Why it's bad: Modifier.Node invalidateDraw() Element.update down up The Final FAQ Alright, now, when we know, what is Modifier.Node and how to use it, it's time for a final piece - - a cheatsheet on choosing which Node to implement. 1. Draw custom visuals in the composable’s bounds → DrawModifierNode DrawModifierNode Use when: You need to paint decorations/overlays (badges, gradients, debug overlays) without changing layout. Use when: // Add a small unread badge in the top-right corner. private class UnreadBadgeNode( var isUnread: Boolean ) : Modifier.Node(), DrawModifierNode { override fun ContentDrawScope.draw() { drawContent() if (isUnread) { val r = 6.dp.toPx() drawCircle( color = Color.Red, radius = r, center = Offset(size.width - r - 2.dp.toPx(), r + 2.dp.toPx()) ) } } } // Add a small unread badge in the top-right corner. private class UnreadBadgeNode( var isUnread: Boolean ) : Modifier.Node(), DrawModifierNode { override fun ContentDrawScope.draw() { drawContent() if (isUnread) { val r = 6.dp.toPx() drawCircle( color = Color.Red, radius = r, center = Offset(size.width - r - 2.dp.toPx(), r + 2.dp.toPx()) ) } } } 2. Enforce or transform size/placement of exactly one child → LayoutModifierNode LayoutModifierNode Use when: You must measure and place the wrapped content (aspect ratio, min touch size, align/offset). Same concepts as Layout, but for a single child. Use when: measure and place Layout // Make content square: size = min(width, height) and center it. private class SquareNode : Modifier.Node(), LayoutModifierNode { override fun MeasureScope.measure(measurable: Measurable, c: Constraints): MeasureResult { val placeable = measurable.measure(c) val side = minOf(placeable.width, placeable.height) return layout(side, side) { val dx = (side - placeable.width) / 2 val dy = (side - placeable.height) / 2 placeable.placeRelative(dx, dy) } } } // Make content square: size = min(width, height) and center it. private class SquareNode : Modifier.Node(), LayoutModifierNode { override fun MeasureScope.measure(measurable: Measurable, c: Constraints): MeasureResult { val placeable = measurable.measure(c) val side = minOf(placeable.width, placeable.height) return layout(side, side) { val dx = (side - placeable.width) / 2 val dy = (side - placeable.height) / 2 placeable.placeRelative(dx, dy) } } } 3. Let the child communicate hints to its parent layout → ParentDataModifierNode parent layout ParentDataModifierNode Use when: The parent needs “extra info” during measurement/placement (e.g., weights, spans, alignment lines). Use when: // Provide a "weight" hint a custom Row/FlowRow parent can read. private class FlowWeightNode(var weight: Float) : Modifier.Node(), ParentDataModifierNode { override fun Density.modifyParentData(parentData: Any?): Any? = (parentData as? FlowItemData ?: FlowItemData()).copy(weight = weight) } data class FlowItemData(val weight: Float = 0f) // Provide a "weight" hint a custom Row/FlowRow parent can read. private class FlowWeightNode(var weight: Float) : Modifier.Node(), ParentDataModifierNode { override fun Density.modifyParentData(parentData: Any?): Any? = (parentData as? FlowItemData ?: FlowItemData()).copy(weight = weight) } data class FlowItemData(val weight: Float = 0f) 4. Add accessibility & test semantics → SemanticsModifierNode SemanticsModifierNode Use when: You need custom labels, actions, or to merge a group into one control (e.g., complex cards). Use when: merge // Make a whole card act as a single button with a clear label. private class CardSemanticsNode( var label: String, var onClick: () -> Unit ) : Modifier.Node(), SemanticsModifierNode { override val shouldMergeDescendantSemantics get() = true override fun SemanticsPropertyReceiver.applySemantics() { contentDescription = label onClick(action = { onClick(); true }) } } // Make a whole card act as a single button with a clear label. private class CardSemanticsNode( var label: String, var onClick: () -> Unit ) : Modifier.Node(), SemanticsModifierNode { override val shouldMergeDescendantSemantics get() = true override fun SemanticsPropertyReceiver.applySemantics() { contentDescription = label onClick(action = { onClick(); true }) } } 5. Handle low-level pointer events & consumption → PointerInputModifierNode PointerInputModifierNode Use when: You need frame-by-frame gesture handling with fine-grained consumption (e.g., swipe-to-dismiss, nested scrolling bridges) and options like out-of-bounds interception or sibling sharing. Density/Config changes should cancel/restart detection. Use when: consumption // Horizontal drag detector that consumes horizontal movement. private class HorizontalDragNode( private val onDelta: (Float) -> Unit ) : Modifier.Node(), PointerInputModifierNode { override fun onPointerEvent(e: PointerEvent, pass: PointerEventPass, bounds: IntSize) { if (pass != PointerEventPass.Main) return e.changes.forEach { change -> val dx = change.positionChange().x if (dx != 0f) { onDelta(dx) change.consume() // prevent siblings/parents from reacting } } } override fun interceptOutOfBoundsChildEvents() = true override fun onCancelPointerInput() { /* reset */ } } // Horizontal drag detector that consumes horizontal movement. private class HorizontalDragNode( private val onDelta: (Float) -> Unit ) : Modifier.Node(), PointerInputModifierNode { override fun onPointerEvent(e: PointerEvent, pass: PointerEventPass, bounds: IntSize) { if (pass != PointerEventPass.Main) return e.changes.forEach { change -> val dx = change.positionChange().x if (dx != 0f) { onDelta(dx) change.consume() // prevent siblings/parents from reacting } } } override fun interceptOutOfBoundsChildEvents() = true override fun onCancelPointerInput() { /* reset */ } } 6. Get final global coordinates (for anchors, portals, tooltips) → GlobalPositionAwareModifierNode global coordinates GlobalPositionAwareModifierNode Use when: You need the final LayoutCoordinates after layout to drive overlays or external systems. Use when: final LayoutCoordinates private class AnchorReporterNode( private val onAnchor: (LayoutCoordinates) -> Unit ) : Modifier.Node(), GlobalPositionAwareModifierNode { override fun onGloballyPositioned(coordinates: LayoutCoordinates) { onAnchor(coordinates) // e.g., show a tooltip anchored to this node } } private class AnchorReporterNode( private val onAnchor: (LayoutCoordinates) -> Unit ) : Modifier.Node(), GlobalPositionAwareModifierNode { override fun onGloballyPositioned(coordinates: LayoutCoordinates) { onAnchor(coordinates) // e.g., show a tooltip anchored to this node } } 7. Read CompositionLocals from a Node → CompositionLocalConsumerModifierNode CompositionLocal CompositionLocalConsumerModifierNode Use when: Your node logic depends on locals (density, layout direction, text style, view configuration). Values are resolved at the attached layout node. Use when: // Flip a chevron for RTL without recomposition. private class RtlAwareChevronNode : Modifier.Node(), DrawModifierNode, CompositionLocalConsumerModifierNode { override fun ContentDrawScope.draw() { val rtl = currentValueOf(LocalLayoutDirection) == LayoutDirection.Rtl drawContent() // draw chevron left/right depending on rtl } } // Flip a chevron for RTL without recomposition. private class RtlAwareChevronNode : Modifier.Node(), DrawModifierNode, CompositionLocalConsumerModifierNode { override fun ContentDrawScope.draw() { val rtl = currentValueOf(LocalLayoutDirection) == LayoutDirection.Rtl drawContent() // draw chevron left/right depending on rtl } } 8. Compose multiple behaviors into one Node → DelegatingNode DelegatingNode Use when: You want a single modifier API that internally combines several node types (e.g., a “parallax-and-fade” effect). Use when: single // Package multiple nodes under one public modifier. private class ParallaxFadeNode( parallax: Float, fadeEdgePx: Float ) : DelegatingNode(), DrawModifierNode { private val parallaxNode = delegate(ParallaxNode(parallax)) // layout/draw shift private val fadeNode = delegate(FadeEdgeMaskNode(fadeEdgePx)) // draw mask override fun ContentDrawScope.draw() = drawContent() // work done by delegates } // Package multiple nodes under one public modifier. private class ParallaxFadeNode( parallax: Float, fadeEdgePx: Float ) : DelegatingNode(), DrawModifierNode { private val parallaxNode = delegate(ParallaxNode(parallax)) // layout/draw shift private val fadeNode = delegate(FadeEdgeMaskNode(fadeEdgePx)) // draw mask override fun ContentDrawScope.draw() = drawContent() // work done by delegates } Conclusion Modifier.Node is the modern, scalable way to build custom UI behavior in Compose: a persistent object that survives recomposition, exposes real lifecycle hooks, and lets you invalidate exactly the phases that changed - draw, measure, placement, semantics - without dragging the whole tree through recomposition. It replaces the churn and equality pitfalls of Modifier.composed with predictable, phase-aware performance. Modifier.Node Modifier.composed If you want to remember only key things, make it these: Own state inside the Node. Push fast-changing values into the node and update via your ModifierNodeElement.update(). No extra recompositions needed. Use the lifecycle. Start work in onAttach(), stop it in onDetach(), and scope coroutines to coroutineScope to avoid leaks. Invalidate surgically. Call invalidateDraw()/invalidateMeasurement() instead of nudging composition. Pick the right role. Draw? DrawModifierNode. Layout? LayoutModifierNode. Semantics, pointer input, parent data, or global coordinates? Use the specific interfaces from the FAQ to keep responsibilities tight. Own state inside the Node. Push fast-changing values into the node and update via your ModifierNodeElement.update(). No extra recompositions needed. Own state inside the Node. ModifierNodeElement.update() Use the lifecycle. Start work in onAttach(), stop it in onDetach(), and scope coroutines to coroutineScope to avoid leaks. Use the lifecycle. onAttach() onDetach() coroutineScope Invalidate surgically. Call invalidateDraw()/invalidateMeasurement() instead of nudging composition. Invalidate surgically. invalidateDraw() invalidateMeasurement() Pick the right role. Draw? DrawModifierNode. Layout? LayoutModifierNode. Semantics, pointer input, parent data, or global coordinates? Use the specific interfaces from the FAQ to keep responsibilities tight. Pick the right role. DrawModifierNode LayoutModifierNode Your next step is simple: identify one composed {} modifier in your codebase, rewrite it as a Node using the factory → element → node pattern, and measure. You’ll ship the same behavior with less recomposition, fewer allocations, and cleaner APIs - exactly what high-performance Compose code looks like. composed {}