Ordering Modifier Chains

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/ordering-modifier-chainsThe 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 diagnose and fix Jetpack Compose Modifier ordering bugs — wrong paint region for background, wrong click area for clickable, wrong clipping for clip, wrong measurement for padding/size, surprising…

---
name: ordering-modifier-chains
description: Use this skill to diagnose and fix Jetpack Compose Modifier ordering bugs — wrong paint region for background, wrong click area for clickable, wrong clipping for clip, wrong measurement for padding/size, surprising graphicsLayer scope. Covers the wrap-the-next-modifier mental model, the canonical pitfalls (padding vs background, clickable placement, clip before background, graphicsLayer placement), and why hoisting an entire Modifier chain via remember { Modifier.... } is rarely a real perf win because Compose already interns identical chains. Use when the developer asks "why does the click area extend past the visible button", "why is my background painted in the wrong place", "does Modifier order matter", "should I cache my Modifier chain", or reviews a diff that reorders modifiers.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - modifier-order
  - clickable
  - clip
  - background
  - padding
  - graphics-layer
  - touch-target
---

# Ordering Modifier Chains — Why `padding(8.dp).background(Red)` ≠ `background(Red).padding(8.dp)`

Modifier order matters because each modifier wraps the next as a function. `Modifier.padding(8.dp).background(Red)` shrinks constraints first, so the background paints INSIDE the padded region — the surrounding 8 dp margin has no red. Conversely, `Modifier.background(Red).padding(8.dp)` paints red across the parent's full bounds before insetting the content. Wrong order is the most common Compose UI bug after missing keys. This skill teaches Claude how to read a chain top-to-bottom and reorder it correctly.

## When to use this skill

- The developer asks "why does the click area extend past the visible button?", "why is my ripple bouncing on the wrong shape?", "why is the background painted in the wrong area?", or "does `Modifier` order matter?".
- A code review shows a chain like `Modifier.padding(...).clickable { }`, `Modifier.background(...).clip(...)`, or `Modifier.alpha(state.value).graphicsLayer { }`.
- A button's tap target leaks into the surrounding padding, or the corner radius is not honored on the background.
- A clip on a parent is failing to mask a child draw, or `graphicsLayer { alpha = 0.5f }` is half-applying to siblings.
- The developer is considering hoisting a `Modifier` chain via `remember { Modifier.... }` "for perf".

## When NOT to use this skill

- The chain order is correct and the symptom is elsewhere (state read in the wrong phase, missing keys in a lazy layout). Diagnose with `../../recomposition/deferring-state-reads/SKILL.md` or `../../lists/optimizing-lazy-layouts/SKILL.md` first.
- The custom modifier itself is the problem (`composed { }` legacy, missing diff) → see `../migrating-to-modifier-node/SKILL.md`.
- The question is whether to make a custom modifier — this skill assumes you already have a chain of built-ins and need to order them right.

## Prerequisites

- Basic familiarity with `Modifier` composition vocabulary (`padding`, `background`, `clip`, `clickable`, `graphicsLayer`).
- Compose UI any supported version — modifier ordering semantics have been stable since 1.0.
- A real-device, release build for any final perf claim about hoisting (skydoves hot take #5: debug builds lie).

## Workflow

- [ ] **1. Identify the symptom precisely.** Match it to one of: paint region wrong, click / pointer area wrong, ripple bounds wrong, clip area wrong, padding measurement wrong, `graphicsLayer` scope wrong. Each maps to a specific reorder.

- [ ] **2. Read the chain top-to-bottom — each modifier's effect applies to everything BELOW it.** Treat the chain as nested function calls: `Modifier.a().b().c()` means "a wraps (b wraps (c))". The top modifier is the outermost wrapper; the bottom modifier is closest to the content.

- [ ] **3. Apply the canonical reorder for the symptom.** The patterns below cover the four most common cases (`padding` vs `background`, `clickable` placement, `clip` before `background`, `graphicsLayer` scope).

- [ ] **4. Pay special attention to these modifiers — order is observable, not stylistic:**
  - `clickable` — the pointer hit area is the bounds AT ITS POSITION in the chain. Anything ABOVE it (outer) is included; anything BELOW it (inner) is not.
  - `clip` — clips everything BELOW it (inner). Anything ABOVE it is unclipped.
  - `background` — paints across the bounds AT ITS POSITION in the chain.
  - `padding` — subtracts from the available space passed to everything BELOW it.
  - `graphicsLayer` — wraps everything BELOW it in a render layer (alpha, transforms, clipping all apply to the subtree under it).

- [ ] **5. Decide on touch-target accessibility.** Material's 48dp minimum touch target is achieved by placing `clickable` ABOVE the visual padding so the padded area is tappable. The trade-off: ripples will also fire in the padding. For visual-area-only clicks, `clickable` goes BELOW `padding`.

- [ ] **6. Resist hoisting a `Modifier` chain via `remember` "for perf".** Compose already interns structurally-equal `Modifier` chains internally; `remember { Modifier.fillMaxWidth().padding(16.dp) }` is a micro-optimization that rarely shows up in a profile. **MUST NOT** add such a `remember` without first proving with a `FrameTimingMetric` benchmark that the unhoisted chain measurably regresses. See `../../lists/optimizing-lazy-layouts/SKILL.md` for the broader allocation-in-items lambda discussion.

## Patterns

### Pattern: background OUTSIDE vs INSIDE padding

```kotlin
// WRONG (when the intent is "padded box with red fill")
Box(Modifier.padding(8.dp).background(Color.Red))
// WRONG because: padding is applied first; background then paints across the inner (padded) bounds — the result is a smaller red region, with no red in the padded margin. If the design intent was "red card with 8dp internal padding", red is on the wrong side of the padding.
```

```

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 Ordering Modifier Chains

• 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