State Hoisting: ridicarea stării și fluxul unidirecțional în Compose

Ce este State Hoisting în Jetpack Compose

State Hoisting (ridicarea stării) — este un pattern în care funcția Composable nu deține starea, ci o primește din exterior. În loc de var în interiorul funcției, se folosesc doi parametri: valoarea pentru afișare și un lambda-callback pentru gestionarea modificărilor. Tehnic, aceasta înseamnă că componenta copil devine stateless (nu are stare proprie), iar părintele devine stateful (deține starea).

Exemplu: componenta TextField din Material3 nu stochează textul introdus în interiorul său. Aceasta primește value: String și onValueChange: (String) -> Unit. Părintele care apelează TextField declară var value by remember { mutableStateOf("") } și transmite value și onValueChange. Acesta este un State Hoisting clasic: TextField — componentă simplă (doar afișează și raportează introducerea), părintele — inteligent (deține starea).

Stateless vs Stateful: O componentă Stateless este mai ușor de testat — nu depinde de starea internă, comportamentul său este complet determinat de parametrii de intrare. O componentă Stateful este convenabilă pentru prototipare rapidă, dar mai dificil de reutilizat — este strict legată de o singură sursă de date. State Hoisting oferă alegerea: orice componentă poate fi făcută stateless prin mutarea stării în sus.

Fluxul unidirecțional de date (UDF) și State Hoisting

UDF (Unidirectional Data Flow) — este un principiu arhitectural în care datele se mișcă într-o singură direcție: de la sursa de adevăr (ViewModel sau părintele Composable) către UI, iar evenimentele în direcția opusă. State Hoisting este implementarea UDF la nivelul componentelor individuale. În loc ca fiecare componentă să decidă singură când și cum să-și schimbe starea, aceasta raportează evenimentul părintelui, iar părintele decide cum să modifice starea.

Avantajele UDF: predictibilitate — starea se schimbă doar într-un singur loc, ceea ce elimină race conditions; traceability — prin stiva de apeluri se poate reconstitui lanțul de modificări; testare — logica stateful poate fi extrasă într-o clasă separată și testată fără UI. În proiectele mari, UDF combinat cu State Hoisting este un standard de facto.

Sursă unică de adevăr (Single Source of Truth) — un alt principiu care însoțește UDF. Fiecare fragment de stare are exact o sursă. Dacă două componente folosesc aceeași stare, sursa trebuie să fie comună (la nivel de ViewModel sau părinte comun). State Hoisting garantează că sursa se află mai sus în ierarhie și nu are loc duplicarea stării.

Regulile State Hoisting: când și cum să ridicăm starea

Regula principală: starea trebuie ridicată la cel mai mic nivel posibil, suficient pentru toate componentele care au nevoie de ea. Dacă starea este folosită doar în interiorul unei singure componente — păstrați-o locală. Dacă două componente vecine au nevoie de aceeași stare — ridicați-o la părintele comun. Dacă starea este necesară pe întreg ecranul — ridicați-o în ViewModel.

Regula ridicării minime previne complexitatea inutilă. Nu are sens să ridicați starea unui câmp text în ViewModel dacă este folosită doar în interiorul unui singur ecran și nu se păstrează la recrearea Activity. Folosiți rememberSaveable la nivelul părintelui ecranului, nu ViewModel, pentru starea UI care trebuie să supraviețuiască rotației ecranului, dar nu este necesară logicii de afaceri.

Când să ridicați în ViewModel: dacă starea trebuie păstrată la recrearea Activity, dacă este necesară mai multor ecrane, dacă modificarea stării declanșează logică de afaceri (cereri de rețea, baze de date). State Hoisting la nivel de ViewModel este un pattern tipic în arhitectura MVVM, unde stratul UI este stateless, iar ViewModel este stateful.

    // ❌ Rău: componenta deține propria stare
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Bine: State Hoisting — starea în părinte
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Utilizare: părintele deține starea
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

Exemple de State Hoisting în componente reale

Luați în considerare ecranul de autentificare care are două câmpuri (email, parolă) și un buton. Toate cele trei componente primesc starea prin State Hoisting: email și parola sunt gestionate de părinte, butonul primește statusul enabled ca valoare.

    // State Hoisting la nivel de ecran
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

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

        // Câmp parolă — similar
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Buton — primește doar enabled (read-only)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Componentă stateless: primește email + callback
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("Email") },
        singleLine = true
    )
}

// Componentă buton stateless
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Autentificare")
    }
}

EmailField și PasswordField — complet stateless. Ele pot fi reutilizate pe orice ecran, conectate la orice sursă de date. LoginButton primește enabled ca read-only — aceasta este o altă formă de State Hoisting în care starea nu este ridicată (butonul nu se poate activa singur), ci este transmisă gata făcută. Această abordare oferă maximă flexibilitate cu o cuplare minimă a componentelor.

State Hoisting vs stare locală: criterii de selecție

Nu orice stare trebuie ridicată. Starea locală (State în interiorul Composable) este justificată atunci când: datele sunt necesare doar într-o singură componentă, nu afectează elementele vecine, nu trebuie să supraviețuiască recompoziției unei secțiuni specifice. De exemplu, starea animației, focusul câmpului de intrare, poziția curentă de scroll — este rezonabil să le păstrați local.

Când State Hoisting este necesar: starea este folosită de mai multe componente copil; modificarea într-un copil trebuie să se reflecte în altul; trebuie să testați logica de modificare a stării separat de UI; starea trebuie păstrată la recrearea Activity. În aceste cazuri, starea locală creează duplicare și inconsistență a datelor.

Abordarea hibridă: păstrați starea minimă local, ridicați restul. Regula Compose: „ridicați starea atât de sus cât este necesar și atât de jos cât este posibil”. În practică, aceasta înseamnă să începeți cu remember local și doar când apare nevoia de acces dintr-o altă componentă — să ridicați nivelul. Nu faceți State Hoisting preventiv — complică codul fără necesitate.