State hoisting

The bug you have not hit yet

Everything you built in Part 3 kept its state where it was used. A counter remembered its own count. A switch remembered its own on-or-off.

That works right up until the moment two things need the same fact.

Picture a shopping list screen with a "3 items" badge at the top and a list underneath. If the list remembers the items and the badge remembers the count, you now have two truths. Delete an item and the list says two while the badge still says three. Nobody wrote a bug. The bug is the shape.

State hoisting is the fix, and it is one of about five ideas that separate an app that works from an app that keeps working.

Two versions of the same button

Here is a counter that owns its state. It is the version you would write first, and there is nothing wrong with it — until there is.

1@Composable
2fun Counter() {
3  var count by remember { mutableStateOf(0) }
4  Button(onClick = { count++ }) {
5    Text("Tapped $count times")
6  }
7}

Now the hoisted version. The state has moved out. What is left takes a value and a lambda.

1@Composable
2fun Counter(
3  count: Int,
4  onTap: () -> Unit
5) {
6  Button(onClick = onTap) {
7    Text("Tapped $count times")
8  }
9}

Read those two side by side. The second one has no remember, no var, no mutableStateOf. It cannot change anything. Hand it the same count twice and it draws the same thing twice, forever.

That property has a name: the composable is now stateless. It is a pure description of pixels, given some data.

Who holds it now?

Somebody still has to. The state moves up to whoever needs it — usually the closest parent that contains everything that cares.

1@Composable
2fun CounterScreen() {
3  var count by remember { mutableStateOf(0) }
4
5  Column {
6    Text("Total so far: $count")
7    Counter(count) { count++ }
8    Counter(count) { count++ }
9  }
10}

Two buttons, one number. Tap either and both buttons update, and the total at the top updates, because there is only one number in the entire screen. There is nothing left to get out of step.

State down, events up

The hoisted Counter has exactly two kinds of parameter, and almost every well-shaped composable in Android has the same two:

Data flows down. Events flow up. Nothing goes sideways, and nothing goes down and then quietly back up again through the same door. That loop has a name — unidirectional data flow — and it is the reason you can look at a Compose screen and work out where a value came from.

Notice the naming convention too. A parameter called value pairs with a lambda called onValueChange. checked pairs with onCheckedChange. Material's own components are built exactly this way, which is why Switch needs both.

You have already done this

Open Dice Duel and look at DieFace:

That single design choice is why the same composable appears twice in the app — once as the big playable die, once as a small trophy on the win banner — with no duplicated code and no flags.

What this buys you

Reuse. One DieFace, two jobs.

Previews. A stateless composable can be drawn in a @Preview with made-up values, because you can just hand it a five. A stateful one draws whatever it happens to remember.

Testing. You can check that passing 6 draws six pips without launching an app.

A place to go next. Once state has left the composable, it can keep going up: out of the screen entirely, into a ViewModel that survives the screen being destroyed. That is the next lesson, and it is only possible because you hoisted first.