Using Efficient Effects

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 87cfb886f00d · 16 Oct 2026Report an issue or request a re-scan

• Publisherskydoves GitHub userOwner of the repository this skill is read from
• Source folderskydoves/compose-performance-skills/side-effects/using-efficient-effectsThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict87cfb886f00dA new audit runs when the source changes
• Repository statusNot archivedLast push 121 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use this skill to choose the cheapest correct effect API in Jetpack Compose — `LaunchedEffect`, `DisposableEffect`, `SideEffect`, `rememberUpdatedState`, and skydoves/compose-effects' `RememberedEffect` and…

---
name: using-efficient-effects
description: Use this skill to choose the cheapest correct effect API in Jetpack Compose — `LaunchedEffect`, `DisposableEffect`, `SideEffect`, `rememberUpdatedState`, and skydoves/compose-effects' `RememberedEffect` and `ViewModelStoreScope`. Covers stale-callback bugs in long-lived `LaunchedEffect`, setup/teardown for non-coroutine subscribers, avoiding a coroutine scope just to react to a key change, and per-row ViewModels in a `LazyColumn`. Trigger when the user mentions LaunchedEffect, DisposableEffect, RememberedEffect, SideEffect, rememberUpdatedState, ViewModelStoreScope, effect restarts unexpectedly, leaked listener, or per-item ViewModel.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - launchedeffect
  - disposableeffect
  - rememberedeffect
  - rememberupdatedstate
  - viewmodelstorescope
  - side-effects
---

# Using Efficient Effects — pick the cheapest correct effect API

Compose ships three effect APIs by default: `LaunchedEffect` (coroutine, restarts on key change), `DisposableEffect` (setup/teardown with a cleanup block), and `SideEffect` (runs on every successful composition). The `skydoves/compose-effects` library adds `RememberedEffect` — a non-coroutine analog of `LaunchedEffect`. Picking the wrong API wastes a coroutine scope, leaks a listener, or silently drops the latest version of a callback. This skill is the decision tree.

## When to use this skill

- The user asks which effect API to choose, or why a `LaunchedEffect` restarts unexpectedly.
- A long-lived `LaunchedEffect` calls a stale version of a callback that the parent has updated.
- A non-Compose subscriber (listener, observer, broadcast receiver, GL surface) needs setup at composition entry and teardown on key change or exit.
- A composable just needs to react to a key change synchronously and a coroutine scope is overkill.
- A `LazyColumn` row needs its own `ViewModel` instance (e.g. one VM per chat row, one VM per feed card) and the parent VM store would leak state across rows.
- The user is debugging unexpected effect restarts, leaked listeners, or per-frame allocations from `SideEffect`.

## When NOT to use this skill

- Pure derivation of one `State<T>` from another — use `derivedStateOf`. See `../../recomposition/choosing-derivedstateof/SKILL.md`.
- Collecting a flow that originates outside the composition — use `collectAsStateWithLifecycle`. See `../collecting-flows-safely/SKILL.md`.
- One-shot computation that must survive recomposition without re-running — use `remember { ... }`, not `LaunchedEffect(Unit)`.

## Prerequisites

- Familiarity with Compose's composition lifecycle: enter, recompose, leave. Effects run after composition commits.
- Compose UI 1.4+.
- For `RememberedEffect`, add `com.github.skydoves:compose-effects` (latest GA — see https://github.com/skydoves/compose-effects).
- For `ViewModelStoreScope`, also depend on `com.github.skydoves:compose-effects-viewmodel`. Import path: `com.skydoves.compose.effects.viewmodel.ViewModelStoreScope`.
- For `ViewModelStoreScope` with Hilt, also `androidx.hilt:hilt-navigation-compose` for `hiltViewModel()`.

## Workflow — decision tree

1. **Need a coroutine?** → `LaunchedEffect(key1, key2, ...)`. The block is launched in the composition's `CoroutineScope` and cancelled/relaunched whenever any key changes. Use for network calls, animations, suspending work.
2. **Need setup + cleanup with no coroutine?** → `DisposableEffect(key) { onDispose { ... } }`. The `onDispose` block runs on key change AND when the composable leaves composition. Use for listeners, observers, manual subscriptions.
3. **Need to react synchronously to a key change with no coroutine?** → `RememberedEffect(key) { ... }` from `skydoves/compose-effects`. Cheaper than spinning a `LaunchedEffect` scope just to call a synchronous function. No `onDispose` — pair with `DisposableEffect` if you need teardown.
4. **Long-lived `LaunchedEffect` that consumes a callback that may change?** → wrap the callback with `val latest by rememberUpdatedState(callback)` and reference `latest` inside the effect. The effect keeps the same coroutine; the callback reference stays fresh.
5. **Per-composable `ViewModel` (one per row in a `LazyColumn`, etc.)?** → wrap the row body in `ViewModelStoreScope(key = <stableId>) { ... }` from `com.github.skydoves:compose-effects-viewmodel` and call `hiltViewModel()` (or `viewModel()`) inside. The `key` is required and must be a stable identifier (the row's id, etc.); each key gets its own store.
6. **Side effect that must run after every successful composition?** → `SideEffect { ... }`. Rare. Use for publishing Compose state to a non-Compose system that you cannot subscribe to via `DisposableEffect` (e.g. updating a `View`'s field on every commit). Avoid for per-frame work — it really does run every commit.

## Patterns

### Pattern: stale callback inside a long-lived `LaunchedEffect`

```kotlin
// WRONG
@Composable
fun Timer(onTick: () -> Unit) {
    LaunchedEffect(Unit) {
        while (true) {
            delay(1_000)
            onTick()
        }
    }
}
// WRONG because: onTick is captured by the first composition's value; later parents pass an
// updated lambda but the running coroutine still holds the original reference -> the new
// onTick is silently ignored.
```

```kotlin
// RIGHT
@Composable
fun Timer(onTick: () -> Unit) {
    val latest by rememberUpdatedState(onTick)
    LaunchedEffect(Unit) {
        while (true) {
            delay(1_000)
            latest()
        }
    }
}
// rememberUpdatedState updates the ref on every recomposition; the coroutine reads the freshest
// reference each tick without restarting.
```

### Pattern: `DisposableEffect` for a non-coroutine subscriber

```kotlin
// WRONG
@Composable
fun LocationBadge(client: LocationClient) {
    LaunchedEffect(client) {
        try {
            val lis

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/skydoves/compose-performance-skills
git -C compose-performance-skills checkout 87cfb886f00d

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 87cfb886f00d

Questions about Using Efficient Effects

• github.com/skydoves/compose-performance-skills/tree/main/side-ef — the audited source at commit 87cfb886f00d and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology