Avoid These 10 Common Jetpack Compose Side‑Effect Mistakes

Preface

Managing side effects in Jetpack Compose is crucial; mishandling them can cause unexpected behavior, poor performance, or inefficient code. This article explores the most common mistakes when dealing with Compose side effects and offers insights on how to avoid them, benefiting developers of all experience levels.

1. Incorrect LaunchedEffect key

Problem Analysis

One of the most common errors is using LaunchedEffect without specifying a proper key or using the wrong key. LaunchedEffect runs its side effect when the key changes; an incorrect key can cause the effect to fire too often or not at all.

// Wrong example: no key, effect runs on every recomposition
LaunchedEffect(Unit) {
    // simulate side effect, e.g., network request
    performNetworkRequest()
}

// Wrong example: using a fixed key
val wrongKey = "fixedKey"
LaunchedEffect(wrongKey) {
    // simulate side effect, e.g., start animation
    startAnimation()
}

If the key is not set correctly, the side effect runs on every recomposition, leading to performance problems.

Solution

Ensure the key participates in the side‑effect computation so that the effect updates only when the key changes.

LaunchedEffect(someState) {
    // Runs only when 'someState' changes
    performSomeAction(someState)
}

2. Using LaunchedEffect with MutableState directly

Problem Analysis

Developers sometimes pass a MutableState object itself to LaunchedEffect, expecting the effect to trigger when the state's value changes. Because remember preserves the object reference, the effect never reacts to value changes.

val mutableState = remember { mutableStateOf(0) }
// Wrong: passing the state object
LaunchedEffect(mutableState) {
    updateUI()
}

Solution

Pass the state's value (a primitive or immutable type) instead of the state object.

val mutableState = remember { mutableStateOf(0) }
LaunchedEffect(mutableState.value) {
    // Runs only when the value changes
    updateUI()
}

3. Misusing remember for frequently changing values

Problem Analysis

Using remember to store values that change often can cause the side effect to work with stale data because remember caches the value across recompositions.

var frequentlyChangingValue by remember { mutableStateOf(0) }
val rememberedValue = remember { frequentlyChangingValue }
LaunchedEffect(rememberedValue) {
    if (rememberedValue > 0) {
        performLogic(rememberedValue)
    }
}

Solution

Use rememberUpdatedState to always get the latest value inside the effect without restarting it.

var frequentlyChangingValue by remember { mutableStateOf(0) }
val currentValue by rememberUpdatedState(frequentlyChangingValue)
LaunchedEffect(currentValue) {
    // Always uses the latest value
    performLogic(currentValue)
}

4. Not cleaning up after side effects

Problem Analysis

Developers often forget to handle cleanup for long‑running tasks (network requests, animations, listeners) when the side effect is no longer needed, leading to memory leaks or coroutines running after the composable is disposed.

var isNetworkRequestInProgress by remember { mutableStateOf(true) }
LaunchedEffect(isNetworkRequestInProgress) {
    if (isNetworkRequestInProgress) {
        val job = launch {
            val response = performNetworkRequest()
            // handle response
        }
    }
}

Solution

Use DisposableEffect to perform cleanup when the composable leaves the composition.

var isNetworkRequestInProgress by remember { mutableStateOf(true) }
DisposableEffect(isNetworkRequestInProgress) {
    val job = launch {
        val response = performNetworkRequest()
        // handle response
    }
    onDispose {
        // Cancel coroutine and clean up
        job.cancel()
    }
}

5. Incorrect coroutine scope in side effects

Problem Analysis

Launching coroutines inside LaunchedEffect with an improper scope (e.g., GlobalScope) can cause memory leaks or premature cancellation when the composable is recomposed or removed.

LaunchedEffect(Unit) {
    // Wrong: using GlobalScope
    val job = GlobalScope.launch {
        delay(5000)
        // handle result
    }
}

Solution

Coroutines started in LaunchedEffect automatically inherit the composable's lifecycle, so no extra scope is needed.

LaunchedEffect(Unit) {
    // Correct: uses the effect's scope
    launch {
        delay(5000)
        // handle result
    }
}

6. Not handling configuration changes

Problem Analysis

Configuration changes (e.g., screen rotation) can cause side effects to fire multiple times or not at all if not managed correctly.

var someValue by remember { mutableStateOf(0) }
LaunchedEffect(Unit) {
    // May trigger incorrectly on configuration change
    if (someValue > 0) {
        performAction()
    }
}

Solution

Use remember to retain values across recompositions and control when the effect runs.

var someValue by remember { mutableStateOf(0) }
val rememberedValue = remember { someValue }
LaunchedEffect(rememberedValue) {
    if (rememberedValue > 0) {
        performAction()
    }
}

7. Using SideEffect for business logic

Problem Analysis

SideEffect is intended for UI‑related side effects (e.g., logging). Using it for business‑logic calculations makes code less predictable and harder to maintain.

SideEffect {
    // Wrong: business logic inside SideEffect
    val result = performBusinessLogicCalculation()
    updateBusinessState(result)
}

Solution

Handle business logic in a ViewModel and trigger it from LaunchedEffect or DisposableEffect.

// In ViewModel
class MyViewModel : ViewModel() {
    fun performBusinessLogic() {
        val result = performBusinessLogicCalculation()
        updateBusinessState(result)
    }
}

// In composable
val viewModel = viewModel<MyViewModel>()
LaunchedEffect(Unit) {
    viewModel.performBusinessLogic()
}

8. Ignoring composability

Problem Analysis

Side effects that cause unnecessary recompositions break Compose's declarative nature and degrade performance.

var someState by remember { mutableStateOf(0) }
// Wrong: side effect causing extra recomposition
LaunchedEffect(someState) {
    val newState = someState + 1
    someState = newState
}

Solution

Use derived state or other state‑management techniques to avoid redundant recompositions.

var someState by remember { mutableStateOf(0) }
val newState = remember { derivedStateOf { someState + 1 } }
LaunchedEffect(newState.value) {
    performAction(newState.value)
}

9. Confusing remember and rememberCoroutineScope

Problem Analysis

Using remember to store a CoroutineScope detaches the coroutine from the composable's lifecycle, leading to errors and performance issues.

// Wrong: managing coroutine scope with remember
val coroutineScope = remember { CoroutineScope(Dispatchers.Main) }
LaunchedEffect(Unit) {
    coroutineScope.launch {
        delay(3000)
        // handle result
    }
}

Solution

Use rememberCoroutineScope to obtain a scope that is tied to the composable's lifecycle.

val coroutineScope = rememberCoroutineScope()
LaunchedEffect(Unit) {
    coroutineScope.launch {
        delay(3000)
        // handle result
    }
}

10. Triggering UI changes directly from side effects

Problem Analysis

Using side effects to drive navigation or UI state changes makes the UI flow hard to manage and test.

var shouldNavigate by remember { mutableStateOf(false) }
LaunchedEffect(shouldNavigate) {
    if (shouldNavigate) {
        // Uncontrolled navigation
        navigateToNewScreen()
    }
}

Solution

Manage UI state and navigation through a ViewModel and Compose's state mechanisms; reserve side effects for non‑UI tasks such as network calls.

// ViewModel handles navigation state
class NavigationViewModel : ViewModel() {
    val navigateFlow = MutableSharedFlow<Boolean>()
    suspend fun navigate() { navigateFlow.emit(true) }
}

val viewModel = viewModel<NavigationViewModel>()
LaunchedEffect(Unit) {
    viewModel.navigateFlow.collect { shouldNavigate ->
        if (shouldNavigate) {
            navigateToNewScreen()
        }
    }
}