State Hoisting: zvedání stavu a jednosměrný tok dat v Compose

Co je State Hoisting v Jetpack Compose

State Hoisting (zvedání stavu) — je vzor, při kterém Composable funkce nevlastní stav, ale získává jej zvenčí. Místo var uvnitř funkce se používají dva parametry: hodnota pro zobrazení a lambda-callback pro zpracování změn. Technicky to znamená, že podřízená komponenta se stává stateless (nemá vlastní stav) a nadřazená stateful (vlastní stav).

Příklad: komponenta TextField z Material3 neukládá zadaný text uvnitř sebe. Přijímá value: String a onValueChange: (String) -> Unit. Nadřazený, který volá TextField, deklaruje var value by remember { mutableStateOf("") } a předává value a onValueChange. Toto je klasické State Hoisting: TextField — jednoduchá komponenta (pouze zobrazuje a hlásí vstup), nadřazený — chytrý (vlastní stav).

Stateless vs Stateful: Stateless komponenta se testuje snadněji — nezávisí na vnitřním stavu, její chování je plně určeno vstupními parametry. Stateful komponenta je vhodná pro rychlé prototypování, ale hůře se znovu používá — je pevně vázána na jeden zdroj dat. State Hoisting dává možnost volby: libovolnou komponentu lze učinit stateless přesunutím stavu nahoru.

Jednosměrný tok dat (UDF) a State Hoisting

UDF (Unidirectional Data Flow) — je architektonický princip, při kterém se data pohybují jedním směrem: od zdroje pravdy (ViewModel nebo nadřazený Composable) k UI, a události opačným směrem. State Hoisting je implementace UDF na úrovni jednotlivých komponent. Místo toho, aby každá komponenta sama rozhodovala, kdy a jak změnit svůj stav, hlásí událost nadřazenému a nadřazený rozhoduje, jak stav změnit.

Výhody UDF: předvídatelnost — stav se mění pouze na jednom místě, což eliminuje race conditions; sledovatelnost — ze zásobníku volání lze rekonstruovat řetězec změn; testování — stateful logiku lze vyčlenit do samostatné třídy a testovat bez UI. Ve velkých projektech je UDF v kombinaci se State Hoisting de facto standardem.

Jediný zdroj pravdy (Single Source of Truth) — další princip doprovázející UDF. Každý fragment stavu má přesně jeden zdroj. Pokud dvě komponenty používají stejný stav, zdroj musí být společný (na úrovni ViewModel nebo společného nadřazeného). State Hoisting zaručuje, že zdroj je výše v hierarchii a nedochází k duplikaci stavu.

Pravidla State Hoisting: kdy a jak zvedat stav

Hlavní pravidlo: stav by měl být zvednut na nejnižší možnou úroveň dostatečnou pro všechny komponenty, které jej potřebují. Pokud je stav používán pouze uvnitř jedné komponenty — ponechte jej lokální. Pokud dvě sousední komponenty potřebují stejný stav — zvedněte jej do společného nadřazeného. Pokud je stav potřebný na celé obrazovce — zvedněte jej do ViewModel.

Pravidlo minimálního zvedání zabraňuje zbytečné složitosti. Nemá smysl zvedat stav textového pole do ViewModel, pokud je používán pouze uvnitř jedné obrazovky a není ukládán při opětovném vytvoření Activity. Použijte rememberSaveable na úrovni nadřazeného obrazovky, ne ViewModel, pro UI stav, který musí přežít otočení obrazovky, ale není potřebný pro obchodní logiku.

Kdy zvedat do ViewModel: pokud stav musí být zachován při opětovném vytvoření Activity, pokud je potřebný pro více obrazovek, pokud změna stavu spouští obchodní logiku (síťové požadavky, databáze). State Hoisting na úrovni ViewModel je typický vzor v architektuře MVVM, kde je UI vrstva stateless a ViewModel stateful.

    // ❌ Špatně: komponenta vlastní svůj stav
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Dobře: State Hoisting — stav v nadřazeném
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Použití: nadřazený vlastní stav
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

Příklady State Hoisting v reálných komponentách

Zvažte přihlašovací obrazovku se dvěma poli (email, heslo) a tlačítkem. Všechny tři komponenty získávají stav prostřednictvím State Hoisting: email a heslo jsou spravovány nadřazeným, tlačítko získává status enabled jako hodnotu.

    // State Hoisting na úrovni obrazovky
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // Pole Email — State Hoisting přes lambdu
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // Pole hesla — podobně
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Tlačítko — dostává pouze enabled (read-only)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Stateless komponenta: přijímá email + callback
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("Email") },
        singleLine = true
    )
}

// Stateless komponenta tlačítka
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Přihlásit")
    }
}

EmailField a PasswordField — zcela stateless. Lze je znovu použít na libovolné obrazovce, připojené k libovolnému zdroji dat. LoginButton získává enabled jako read-only — to je další forma State Hoisting, kde stav není zvedán (tlačítko se nemůže samo aktivovat), ale je předáván hotový. Tento přístup poskytuje maximální flexibilitu s minimální provázaností komponent.

State Hoisting vs lokální stav: kritéria výběru

Ne každý stav je třeba zvedat. Lokální stav (State uvnitř Composable) je oprávněný, když: data jsou potřebná pouze uvnitř jedné komponenty, neovlivňují sousední prvky, nemusí přežít recompozici konkrétní sekce. Například stav animace, focus vstupního pole, aktuální pozice scrollování — je rozumné držet lokálně.

Kdy je State Hoisting nezbytný: stav je používán několika podřízenými komponentami; změna v jednom podřízeném se musí odrážet v druhém; je třeba testovat logiku změny stavu odděleně od UI; stav musí být zachován při opětovném vytvoření Activity. V těchto případech lokální stav vytváří duplikaci a nekonzistenci dat.

Hybridní přístup: držte minimální stav lokálně, zbytek zvedněte. Pravidlo Compose: „zvedejte stav tak vysoko, jak je to nutné, a tak nízko, jak je to možné. V praxi to znamená začít s lokálním remember, a teprve když se objeví potřeba přístupu z jiné komponenty — zvednout úroveň. Nedělejte State Hoisting preventivně — komplikuje to kód bez potřeby.