Choosing Derivedstateof

Choosing derivedStateOf — Filter Hot Inputs into Cold Outputs

derivedStateOf produces a State whose readers only invalidate when the derived result changes, even if the input states change far more often. Use it when input frequency exceeds output frequency. Use it for any other shape and it is pure overhead — an extra snapshot subscription with no filtering benefit. This skill teaches Claude when to reach for it, when to refuse, and how to avoid the canonical capture-by-initial-value pitfall.

When to use this skill

• The developer asks whether a value should be wrapped in derivedStateOf.
• A scroll position drives a boolean (firstVisibleItemIndex == 0, scrollState.value > threshold, "show FAB on scroll").
• A high-frequency input (drag delta, animation progress) feeds a low-frequency output (boolean threshold, bucketed integer).
• A derivedStateOf exists in the code but recomposition counts didn't drop, or the value never updates after the first composition (the capture-by-initial-value bug).
• The developer wants a one-shot side effect (analytics, logging, snackbar) when a derived value flips.

When NOT to use this skill

• The state read is in the wrong phase (e.g. Modifier.alpha(state.value)). Fix that with ../deferring-state-reads/SKILL.md first — derivedStateOf does not address phase issues.
• Diagnosing whether a parameter is unstable. That is ../../stability/diagnosing-compose-stability/SKILL.md.
• Input frequency equals output frequency (e.g. "$first $last" from two name states). derivedStateOf is pure overhead in that case — use a direct read or a plain remember.

Prerequisites

• Familiarity with state-read-driven recomposition: a snapshot read inside a restartable composable subscribes that composable's restart scope to the state.
• Compose runtime ≥ 1.0 (the API is foundational; behavior described here is stable).
• Ability to confirm recomposition counts via Layout Inspector or @TraceRecomposition from skydoves/compose-stability-analyzer.

Workflow

• 1. Identify the input state(s) and the value the UI actually consumes. Write down both update frequencies. Example: listState.firstVisibleItemIndex (changes every list item scrolled past) → Boolean (changes once when the user crosses index 0).

• 2. Compare frequencies. Apply the rule:

  • Input updates much more often than output → derivedStateOf is the right tool.
  • Input and output update at roughly the same rate → derivedStateOf adds an extra snapshot subscription for nothing. Use a direct read or a plain remember(input1, input2).

• 3. Wrap the derivation in remember { derivedStateOf { … } }. A bare derivedStateOf { } would be re-created on every composition, defeating the cache. The remember is mandatory.

• 4. If the lambda captures non-state variables (function parameters, locals, props), pass them as remember keys. A captured non-state variable is read once at first composition and frozen forever — the derivation will silently use the stale value. The fix is remember(threshold) { derivedStateOf { … > threshold } }.

• 5. For one-shot side effects on a derived value (logging, analytics, snackbar), prefer snapshotFlow { … }.collect { … } inside LaunchedEffect. That avoids subscribing the composable's restart scope to the derived state; the side effect runs in a coroutine, off the composition path.

• 6. Verify in Layout Inspector / @TraceRecomposition. The consuming composable's recomposition count MUST only increment when the derived result changes — not on every input tick. If it still climbs per input tick, either (a) the derivedStateOf is missing, (b) the remember is missing, or (c) something else (a sibling state read, a wrong-phase modifier) is invalidating the same scope.

Patterns

Pattern: scroll-to-top FAB — input >> output

// WRONG
val showFab = listState.firstVisibleItemIndex > 0
// WRONG because: this reads firstVisibleItemIndex on every recomposition; the consuming composable invalidates per scrolled item, not just when the boolean flips.

// RIGHT
val showFab by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 0 }
}

firstVisibleItemIndex updates on every list item scrolled past; showFab only flips when the user crosses index 0. The remember keeps the derived state alive across compositions; the derivedStateOf filters out every input change that does not flip the boolean.

Pattern: pure overhead — input ≈ output

// WRONG
val first by remember { mutableStateOf("Ada") }
val last by remember { mutableStateOf("Lovelace") }
val fullName by remember { derivedStateOf { "$first $last" } }
// WRONG because: first and last change at the same rate as fullName; derivedStateOf adds a snapshot subscription with zero filtering benefit.

// RIGHT — direct read, no derivedStateOf needed
val first by remember { mutableStateOf("Ada") }
val last by remember { mutableStateOf("Lovelace") }
val fullName = "$first $last"

If a memoization cost concern exists (the concatenation is expensive), use remember(first, last) { computeFullName(first, last) } — derivedStateOf is still the wrong shape because there is nothing to filter.