State Hoisting: State Lifting and Unidirectional Data Flow in Compose

What is State Hoisting in Jetpack Compose

State Hoisting is a pattern where a Composable function does not own state but receives it from outside. Instead of var inside the function, two parameters are used: a value for display and a lambda callback for handling changes. Technically, this means the child component becomes stateless (does not have its own state), while the parent is stateful (owns the state).

Example: the TextField component from Material3 does not store the entered text internally. It accepts value: String and onValueChange: (String) -> Unit. The parent calling TextField declares var value by remember { mutableStateOf("") } and passes value and onValueChange. This is classic State Hoisting: TextField is a dumb component (simply displays and reports input), the parent is smart (owns the state).

Stateless vs Stateful: A stateless component is easier to test — it does not depend on internal state, its behavior is fully determined by input parameters. A stateful component is convenient for rapid prototyping but harder to reuse: it is tightly coupled to a single data source. State Hoisting gives you a choice: any component can be made stateless by moving state upward.

Unidirectional Data Flow (UDF) and State Hoisting

UDF (Unidirectional Data Flow) is an architectural principle where data moves in one direction: from the source of truth (ViewModel or parent Composable) to the UI, and events flow in the opposite direction. State Hoisting is the implementation of UDF at the individual component level. Instead of each component deciding when and how to change its own state, it notifies the parent about an event, and the parent decides how to change the state.

Advantages of UDF: predictability — state changes in only one place, eliminating race conditions; traceability — the call stack allows reconstructing the chain of changes; testing — stateful logic can be extracted into a separate class and tested without UI. In large projects, UDF combined with State Hoisting is the de facto standard.

Single Source of Truth is another principle that accompanies UDF. Each piece of state has exactly one source. If two components use the same state, the source should be shared (at the ViewModel or common parent level). State Hoisting ensures the source is above in the hierarchy and no state duplication occurs.

State Hoisting Rules: When and How to Lift State

The main rule: state should be lifted to the minimum possible level sufficient for all components that need it. If state is only used inside one component — keep it local. If two adjacent components need the same state — lift it to the common parent. If state is needed across the entire screen — lift it to the ViewModel.

The minimum lift rule prevents unnecessary complexity. There is no point in lifting text field state to a ViewModel if it is only used within one screen and is not persisted when the Activity is recreated. Use rememberSaveable at the screen parent level, not ViewModel, for UI state that should survive a screen rotation but is not needed by business logic.

When to lift to ViewModel: if the state must survive Activity recreation, if it is needed by multiple screens, if changing the state triggers business logic (network requests, database). State Hoisting at the ViewModel level is a standard pattern in MVVM architecture, where the UI layer is stateless and the ViewModel is stateful.

    // ❌ Bad: component owns its own state
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Good: State Hoisting — state in parent
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Usage: parent owns the state
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

State Hoisting Examples in Real Components

Consider a login screen with two fields (email, password) and a button. All three components receive state through State Hoisting: email and password are managed by the parent, the button receives its enabled status as a value.

    // State Hoisting at screen level
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // Email field — State Hoisting via lambda
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // Password field — similarly
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Button — receives only enabled (read-only)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Stateless component: receives email + callback
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("Email") },
        singleLine = true
    )
}

// Stateless button component
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Login")
    }
}

EmailField and PasswordField are completely stateless. They can be reused on any screen by connecting them to any data source. LoginButton receives enabled as read-only — this is another form of State Hoisting where state is not lifted (the button cannot enable itself) but is passed down ready-made. This approach provides maximum flexibility with minimal component coupling.

State Hoisting vs Local State: Selection Criteria

Not every state needs to be lifted. Local state (State inside a Composable) is justified when: data is only needed inside one component, it does not affect sibling elements, and it should not survive recomposition of a specific section. For example, animation state, input field focus, current scroll position — these are reasonable to keep locally.

When State Hoisting is necessary: state is used by multiple child components; a change in one child should be reflected in another; the logic of state changes needs to be tested separately from the UI; state should survive Activity recreation. In these cases, local state creates duplication and data inconsistency.

Hybrid approach: keep minimal state locally, lift the rest. The Compose rule: "lift state as high as necessary and as low as possible." In practice, this means starting with local remember and only lifting the level when access from another component is needed. Do not apply State Hoisting preemptively — it complicates code without necessity.