In Compose, the order of your modifiers is code — not decoration

In Jetpack Compose, you style and position a UI element by chaining modifiers: Modifier.padding(16.dp).background(Color.Blue).clickable { … }. It looks like a bag of independent settings, but it isn't. Each modifier wraps the result of the one before it, so the chain is evaluated left to right, like layers of an onion. Reorder the chain and you change the outcome, even though every individual call is identical.

The classic example is padding versus clickable. Put .clickable {} before .padding() and the padding becomes part of the tappable area — taps on the empty margin still fire. Put .padding() first and that same margin is now dead space that ignores taps. Same modifiers, same values, opposite behavior.

The reason is that each modifier only sees the constraints handed down from the modifier above it. padding shrinks the space, then passes the smaller box to whatever comes next. So background before padding paints the full size; background after padding paints only the inset region. This is deliberate: unlike the old Android View system, where margin-vs-padding rules were implicit and easy to get wrong, Compose makes the interaction explicit and predictable — but only if you read the chain as a sequence, not a set.

Rule of thumb: think of the modifier list as a pipeline. What each entry does depends entirely on everything stacked above it.