choosing-derivedstateof

Identify when to apply derivedStateOf to filter high-frequency inputs into stable outputs.

472|16|Updated Apr 29, 2026
One-click install
npx skills add https://github.com/skydoves/compose-performance-skills --skill choosing-derivedstateof
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: choosing-derivedstateof
Source: https://github.com/skydoves/compose-performance-skills/tree/main/recomposition/choosing-derivedstateof
Command: npx skills add https://github.com/skydoves/compose-performance-skills --skill choosing-derivedstateof

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps developers decide whether to use Jetpack Compose's derivedStateOf to filter high-frequency inputs into a stable derived output, preventing unnecessary recompositions.

Core Features & Use Cases

  • Identify when derivedStateOf adds value by filtering input/output frequency.
  • Enforce remember { derivedStateOf { … } } and use remember keys for captured non-state values.
  • Prefer snapshotFlow for one-shot side effects on derived values and avoid triggering recompositions directly.
  • Real-world scenarios include scroll-driven booleans (e.g., show FAB on scroll), threshold checks, and recomposition-tracking diagnostics.

Quick Start

Identify a high-frequency input driving a low-frequency output and wrap the derived computation in remember { derivedStateOf { … } } with non-state captures as remember keys.

Frequently Asked Questions about choosing-derivedstateof

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I use derivedStateOf in Jetpack Compose to reduce recompositions?

DerivedStateOf prevents unnecessary recompositions by wrapping high-frequency state reads to produce low-frequency outputs, like scroll-driven booleans, ensuring only threshold changes trigger UI updates instead of every pixel scroll.

How do I implement derivedStateOf with remember for scroll-driven UI patterns?

Wrap scroll-driven boolean computations in remember { derivedStateOf { … } }, passing captured non-state values as remember keys, to filter high-frequency scroll offsets into stable outputs that prevent excessive recompositions.

What is the difference between derivedStateOf and snapshotFlow for side effects?

Prefer snapshotFlow over derivedStateOf for one-shot side effects on derived values; snapshotFlow emits state changes as a flow without triggering recompositions directly, making it ideal for asynchronous operations.

Can derivedStateOf hurt performance if applied to the wrong state inputs?

DerivedStateOf hurts performance when applied to low-frequency state inputs by adding unnecessary computation overhead without reducing recompositions; verify with Layout Inspector that it genuinely filters high-frequency inputs into stable outputs.

How do I verify if derivedStateOf is actually reducing recompositions in my Compose UI?

Verify derivedStateOf effectiveness by tracking recomposition counts with Layout Inspector, confirming the wrapper successfully filters high-frequency inputs into stable outputs and reduces recomposition frequency.