State & Recomposition in Compose

Reviewed & published by Brayan K

In Compose, UI is a function of state. Change the state and Compose recomposes — re-running the affected composables to redraw the screen. The trick is making that state observable.

Part of the free Kotlin course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

By the end you'll use remember and mutableStateOf, hoist state for reusable composables, and persist state across rotation with rememberSaveable.

What You'll Learn in This Lesson

• How recomposition works
• Creating state with mutableStateOf
• Keeping state with remember
• The 'state down, events up' pattern
• Hoisting state for reusable composables
• Surviving rotation with rememberSaveable

1️⃣ Observable State with remember + mutableStateOf

A plain var won't update the UI — Compose only watches State objects. mutableStateOf makes the value observable; remember keeps it alive across recompositions. The by delegate lets you read and write it like a normal variable.

import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue

@Composable
fun Counter() {
    // remember keeps the value across recompositions.
    // mutableStateOf makes it observable so changes trigger recomposition.
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Clicked $count times")
    }
}

Each tap writes to count; Compose notices the read inside the button label and recomposes just that text.

2️⃣ State Hoisting

A reusable composable should be stateless: it receives the current value and an event callback. The stateful parent owns the data. This is the state down, events up pattern.

import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue

// STATELESS: receives the value and an event callback (state down, events up).
@Composable
fun CounterButton(count: Int, onIncrement: () -> Unit) {
    Button(onClick = onIncrement) {
        Text("Clicked $count times")
    }
}

// STATEFUL: owns the state and passes it down.
@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }
    CounterButton(count = count, onIncrement = { count++ })
}

CounterButton is now decoupled from storage — you can preview it, test it, and reuse it anywhere.

3️⃣ Surviving Rotation with rememberSaveable

Plain remember survives recomposition but not a configuration change like rotation. rememberSaveable persists the value through those too.

import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.saveable.rememberSaveable
import androidx.compose.runtime.setValue

@Composable
fun SurvivingCounter() {
    // rememberSaveable survives recomposition AND rotation
    // (configuration changes), unlike plain remember.
    var count by rememberSaveable { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

Your turn. Replace the TODO, then run and compare.

// 🎯 YOUR TURN — replace the TODO then run in Android Studio.

import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue

@Composable
fun Toggle() {
    // 1) Make 'on' observable state starting at false.
    //    👉 replace TODO with: remember { mutableStateOf(false) }
    var on by TODO

    Button(onClick = { on = !on }) {
        Text(if (on) "ON" else "OFF")
    }
}

Mini-Challenge: A Live Greeter

Bind a TextField to a String state and watch a greeting recompose as you type.

// 🎯 MINI-CHALLENGE: a name greeter.
//
// 1. Write a @Composable Greeter().
// 2. Hold a String state 'name' with remember { mutableStateOf("") }.
// 3. Show a TextField bound to name (value = name,
//    onValueChange = { name = it }).
// 4. Below it, show Text("Hello, $name!").
//
// ✅ As you type "Ada", the Text recomposes to:
//    Hello, Ada!

@Composable
fun Greeter() {
    // your code here
}

Common Errors (and the fix)

• Using a plain var — A normal variable won't recompose the UI. Wrap it in mutableStateOf.
• Forgetting remember — Without it, the state resets to its initial value on every recomposition.
• Missing by imports — The by delegate needs getValue/setValue imports; otherwise use .value.
• Expecting rotation to keep remember — Use rememberSaveable for values that must survive configuration changes.

Pro Tips

• 💡 Single source of truth: hoist state so only one composable owns it.
• 💡 Keep composables stateless where you can: they're easier to preview and test.
• 💡 Reach for rememberSaveable for anything a user would be annoyed to lose on rotation.

📋 Quick Reference — State

🎉 Lesson Complete!

• ✅ Recomposition re-runs composables that read changed state
• ✅ mutableStateOf makes a value observable
• ✅ remember keeps state across recompositions
• ✅ Hoisting yields stateless, reusable composables
• ✅ rememberSaveable survives rotation

Practice quiz

Continue this course

• Previous: Jetpack Compose Basics
• Next: Compose Layouts, Modifiers & Lists — Modifier chains, Box/Column/Row and LazyColumn/LazyRow
• Quick reference: Kotlin cheat sheet

Frequently asked questions

Why do I need both remember and mutableStateOf?

They solve two different problems. mutableStateOf creates an observable State so Compose knows to recompose when the value changes. remember keeps that State object alive across recompositions — without it, every recomposition would create a fresh State and reset to the initial value. You almost always pair them: remember { mutableStateOf(initial) }.

What exactly triggers a recomposition?

Compose tracks which composables read which State values. When you write to a State (for example count++ on a mutableStateOf), Compose schedules recomposition of exactly the composables that read that state. It's smart and fine-grained: unrelated parts of the screen are skipped, which keeps recomposition cheap.

What is state hoisting and why bother?

State hoisting means moving a composable's state up to its caller, so the composable becomes stateless and simply receives a value plus an onValueChange (or onClick) callback. This 'state down, events up' pattern makes composables reusable, easier to test, and gives a single source of truth. The stateful parent owns the data; the stateless child just renders it.

When should I use rememberSaveable instead of remember?

Use rememberSaveable when the value should survive configuration changes such as screen rotation, dark-mode toggles, and even process death — for example the text a user has typed or a selected tab. It stores the value in a Bundle via a Saver. Plain remember only survives recomposition, so the value resets on rotation. For ephemeral, easily recomputed values, plain remember is fine.