Compose Side-Effects: Escaping the Pure Function

Why it exists

Compose's declarative model relies on pure functions for predictable UI rendering. A pure function always returns the same output for the same input and has no other observable effects. However, apps must perform actions that affect things outside the UI, like fetching data or logging analytics. These 'side-effects' would break purity and cause chaos if run directly during composition, as composables can be re-run frequently and unpredictably.

The mental model

A composable is a pure blueprint for UI. Side-effect handlers are the designated, controlled 'construction zones' where you can safely perform real-world work. They tie non-UI logic to a composable's lifecycle, ensuring effects run at the right time (e.g., when the composable first appears) and are cleaned up properly (e.g., cancelling a network call when it leaves the screen). This isolates impurity from the rendering logic.

How it works

Compose provides a set of APIs to manage effects. The most common is LaunchedEffect. You give it one or more 'keys' (often state variables). When the composable enters the composition, it launches a coroutine to execute your effect block. If a key changes, the old coroutine is cancelled and a new one is launched with the new value. If the composable leaves the composition, the coroutine is automatically cancelled. Other handlers like DisposableEffect are for effects that need explicit cleanup logic, and SideEffect is for code that must run after every successful recomposition.

When to use it

Use side-effect handlers whenever a composable needs to trigger a one-off or state-driven action that is not directly creating UI. This includes launching coroutines for data fetching, communicating with other parts of the Android system (like showing a Toast or Snackbar), or subscribing to a data stream that requires manual cancellation.

When not to use it

Do not use side-effect handlers for logic that can be derived directly from state. For example, to show or hide a UI element based on a boolean, use a simple if statement in your composable body. If a state transformation is computationally expensive, use derivedStateOf to memoize the result. Effects are for triggering actions, not for calculating the UI tree itself.

One canonical example

Showing a Snackbar when an error occurs. A ViewModel exposes an error message state. The UI uses LaunchedEffect(key1 = errorMessage) where errorMessage is the state variable. When errorMessage changes from null to a string, the effect launches, calls snackbarHostState.showSnackbar(), and then calls a ViewModel function to clear the error. This ensures the snackbar appears exactly once per error, tied to the lifecycle of the composable.