State Hoisting: podnoszenie stanu i jednokierunkowy przepływ w Compose

Czym jest State Hoisting w Jetpack Compose

State Hoisting (podnoszenie stanu) — to wzorzec, w którym funkcja Composable nie posiada stanu, ale otrzymuje go z zewnątrz. Zamiast var wewnątrz funkcji stosuje się dwa parametry: wartość do wyświetlenia i lambdę-callback do obsługi zmian. Technicznie oznacza to, że komponent podrzędny staje się stateless (nie ma własnego stanu), a nadrzędny — stateful (posiada stan).

Przykład: komponent TextField z Material3 nie przechowuje wprowadzonego tekstu wewnątrz siebie. Przyjmuje value: String i onValueChange: (String) -> Unit. Nadrzędny, wywołujący TextField, deklaruje var value by remember { mutableStateOf("") } i przekazuje value oraz onValueChange. To klasyczny State Hoisting: TextField — komponent głupi (tylko wyświetla i informuje o wprowadzaniu), nadrzędny — mądry (posiada stan).

Stateless vs Stateful: Komponent stateless jest łatwiejszy do testowania — nie zależy od wewnętrznego stanu, jego zachowanie jest w pełni określone przez parametry wejściowe. Komponent stateful jest wygodny do szybkiego prototypowania, ale trudniejszy do wielokrotnego użycia — jest sztywno powiązany z jednym źródłem danych. State Hoisting daje wybór: każdy komponent można uczynić stateless, przenosząc stan wyżej.

Jednokierunkowy przepływ danych (UDF) a State Hoisting

UDF (Unidirectional Data Flow) — to architektoniczna zasada, w której dane płyną w jednym kierunku: od źródła prawdy (ViewModel lub nadrzędny Composable) do UI, a zdarzenia — w przeciwnym kierunku. State Hoisting to realizacja UDF na poziomie poszczególnych komponentów. Zamiast każdego komponentu samodzielnie decydującego, kiedy i jak zmienić swój stan, informuje on nadrzędnego o zdarzeniu, a nadrzędny decyduje, jak zmienić stan.

Zalety UDF: przewidywalność — stan zmienia się tylko w jednym miejscu, co eliminuje race conditions; traceability — na podstawie stosu wywołań można odtworzyć łańcuch zmian; testowanie — logikę stateful można wydzielić do osobnej klasy i testować bez UI. W dużych projektach UDF w połączeniu z State Hoisting to standard de facto.

Pojedyncze źródło prawdy (Single Source of Truth) — kolejna zasada towarzysząca UDF. Każdy fragment stanu ma dokładnie jedno źródło. Jeśli dwa komponenty używają tego samego stanu, źródło musi być wspólne (na poziomie ViewModel lub wspólnego nadrzędnego). State Hoisting gwarantuje, że źródło znajduje się wyżej w hierarchii i nie dochodzi do powielania stanu.

Zasady State Hoisting: kiedy i jak podnosić stan

Główna zasada: stan powinien być podniesiony na minimalny możliwy poziom, wystarczający dla wszystkich komponentów, które go potrzebują. Jeśli stan jest używany tylko wewnątrz jednego komponentu — pozostaw go lokalnym. Jeśli dwa sąsiednie komponenty potrzebują tego samego stanu — podnieś do wspólnego nadrzędnego. Jeśli stan jest potrzebny na całym ekranie — podnieś do ViewModel.

Zasada minimalnego podnoszenia zapobiega niepotrzebnej złożoności. Nie ma sensu podnosić stan pola tekstowego do ViewModel, jeśli jest używany tylko wewnątrz jednego ekranu i nie jest zachowywany przy odtworzeniu Activity. Użyj rememberSaveable na poziomie nadrzędnego ekranu, a nie ViewModel, dla stanu UI, który ma przetrwać obrót ekranu, ale nie jest potrzebny logice biznesowej.

Kiedy podnosić do ViewModel: jeśli stan musi być zachowany przy odtworzeniu Activity, jeśli jest potrzebny wielu ekranom, jeśli zmiana stanu uruchamia logikę biznesową (zapytania sieciowe, BD). State Hoisting na poziomie ViewModel to typowy wzorzec w architekturze MVVM, gdzie warstwa UI jest stateless, a ViewModel — stateful.

    // ❌ Źle: komponent posiada własny stan
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Dobrze: State Hoisting — stan w rodzicu
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Zastosowanie: rodzic posiada stan
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

Przykłady State Hoisting w rzeczywistych komponentach

Rozważmy ekran logowania, na którym są dwa pola (email, hasło) i przycisk. Wszystkie trzy komponenty otrzymują stan przez State Hoisting: email i hasło są zarządzane przez nadrzędnego, przycisk otrzymuje status enabled jako wartość.

    // State Hoisting na poziomie ekranu
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // Pole Email — State Hoisting przez lambdę
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // Pole hasła — podobnie
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Przycisk — otrzymuje tylko enabled (tylko do odczytu)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

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

// Komponent przycisku bezstanowy
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Zaloguj")
    }
}

EmailField i PasswordField — całkowicie stateless. Można je wielokrotnie używać na dowolnym ekranie, podłączając do dowolnego źródła danych. LoginButton otrzymuje enabled jako read-only — to kolejna forma State Hoisting, gdzie stan nie jest podnoszony (przycisk nie może sam się włączyć), ale jest przekazywany gotowy. Takie podejście daje maksymalną elastyczność przy minimalnym powiązaniu komponentów.

State Hoisting vs stan lokalny: kryteria wyboru

Nie każdy stan trzeba podnosić. Stan lokalny (State wewnątrz Composable) jest uzasadniony, gdy: dane są potrzebne tylko wewnątrz jednego komponentu, nie wpływają na sąsiednie elementy, nie muszą przetrwać rekompozycji konkretnej sekcji. Na przykład stan animacji, focus pola wprowadzania, bieżąca pozycja scrolla — warto trzymać lokalnie.

Kiedy State Hoisting jest niezbędny: stan jest używany przez kilka podrzędnych komponentów; zmiana w jednym podrzędnym musi odzwierciedlać się w drugim; trzeba testować logikę zmiany stanu oddzielnie od UI; stan musi być zachowany przy odtworzeniu Activity. W tych przypadkach stan lokalny tworzy powielenie i niespójność danych.

Podejście hybrydowe: trzymaj minimalny stan lokalnie, resztę podnoś. Zasada Compose: „podnoś stan tak wysoko, jak to konieczne, i tak nisko, jak to możliwe”. W praktyce oznacza to zacząć od lokalnego remember, a dopiero gdy pojawi się potrzeba dostępu z innego komponentu — podnieś poziom. Nie stosuj State Hoisting prewencyjnie — to komplikuje kod bez potrzeby.