compose-modifier-and-layout-style
This skill covers the core patterns for writing composables that respect the parent's layout choices. You'll learn to declare a modifier parameter with a default value, apply it to the root layout first, avoid hardcoding positioning decisions, and construct modifier chains as fluent expressions rather than step-by-step reassignments.
compose-modifier-and-layout-style teaches you to declare modifier parameters on composables and apply them to the root layout so parents control positioning.
AI-generated summary based on this skill's SKILL.md
Install
chrisbanes/skills/compose-modifier-and-layout-style · repository language: Python
git clone https://github.com/chrisbanes/skills
cp -r skills/skills/compose-modifier-and-layout-style ~/.claude/skills/compose-modifier-and-layout-styleFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do you declare modifier in composable function with best practices?
compose-modifier-and-layout-style teaches that you should declare a modifier parameter with a default value of `Modifier` at the end of your composable's parameter list, after all required parameters. Apply this modifier to your root layout element first—typically a Column, Box, or Row. This pattern respects the caller's layout choices and prevents hardcoding positioning decisions like `fillMaxWidth` at the root level.
What is the correct way to construct modifier chains in Compose?
compose-modifier-and-layout-style recommends building modifier chains as fluent expressions using dot notation rather than step-by-step reassignments. Write `Modifier.padding(8.dp).fillMaxWidth().clip(RoundedCornerShape(4.dp))` as a single chained expression. This fluent approach is more readable and idiomatic than assigning intermediate results to variables.
How should you apply the caller modifier to root layout in Compose?
compose-modifier-and-layout-style emphasizes that the caller's modifier should be applied to the root layout element first. This ensures the parent's layout decisions take precedence. For example, if your composable receives a `modifier` parameter, pass it directly to your outermost Column or Box before applying any internal layout logic.
When should you hoist if statements outside layout in Compose?
compose-modifier-and-layout-style advises hoisting conditional logic outside your layout composables when the condition determines which composable to render entirely. If you're choosing between different layouts or components based on state, structure the conditional at the call site rather than nesting it inside a single layout. This keeps composable bodies clean and respects layout ownership.
How do you avoid hardcoded root layout decisions in Compose composables?
compose-modifier-and-layout-style teaches that you should never hardcode layout directives like `fillMaxWidth` or `fillMaxHeight` on your root layout. Instead, accept a modifier parameter from the caller and apply it to the root element. This allows parent composables to control sizing and positioning, following the principle that layout ownership belongs to the caller, not the composable itself.
What are measure-phase constraint decorations used for in Compose?
compose-modifier-and-layout-style covers measure-phase constraint decoration as a technique for cross-composable sizing. These decorations allow you to modify layout constraints during the measure phase, enabling composables to communicate sizing requirements and constraints across boundaries in a composable hierarchy.
SKILL.md
rendered from the published skill — quoted content, verbatim
Compose modifier and layout style
Core principle
A composable that emits layout is a leaf the parent places — the parent decides position, size, alignment, padding. The composable's job is structure (what's inside), not placement (where it goes). Three rules follow:
- Declare a
modifierparameter and apply it to the root, so the parent can actually do its job. Hardcoding.fillMaxWidth()on a composable's root takes that decision away from every future caller. - Construct modifier chains as one fluent expression, not stepwise reassignments. Both compile to the same thing, but the chain reads as intent in one pass.
- Conditional rendering belongs where the condition applies. A layout call whose only content is one
ifexists solely to hold the condition — push theifoutside instead.
These travel together because the same composable usually triggers all three: you declare its parameters (rule 1), the
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
skills/compose-modifier-and-layout-style/SKILL.md