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