State Hoisting: повдигане на състоянието и еднопосочен поток в Compose

Какво е State Hoisting в Jetpack Compose

State Hoisting (повдигане на състояние) — е модел, при който Composable функцията не притежава състояние, а го получава отвън. Вместо var внутрен на функцията се използват два параметъра: стойността за показване и лямбда-callback за обработка на промените. Технически това означава, че подчиненият компонент става stateless (няма собствено състояние), а родителският — stateful (притежава състояние).

Пример: компонентът TextField от Material3 не съхранява въведения текст внутре на себе си. Той приема value: String и onValueChange: (String) -> Unit. Родителят, който вика TextField, декларира var value by remember { mutableStateOf("") } и предава value и onValueChange. Това е класическо State Hoisting: TextField — прост компонент (само показва и отчитава въвеждане), родителят — умен (притежава състояние).

Stateless срещу Stateful: Stateless компонент се тества по-лесно — не зависи от вътрешно състояние, поведението му се определя изцяло от входните параметри. Stateful компонент е удобен за бързо прототипиране, но по-трудно се използва повторно — той е здраво свързан с един източник на данни. State Hoisting дава избор: всяка компонента може да бъде направена stateless чрез преместване на състоянието нагоре.

Еднопосочен поток на данни (UDF) и State Hoisting

UDF (Unidirectional Data Flow) — е архитектурен принцип, при който данните се движат в една посока: от източника на истината (ViewModel или родителски Composable) към UI, а събитията в обратната посока. State Hoisting е изпълнението на UDF на ниво на отделни компоненти. Вместо всяка компонента сама да решава кога и как да промени състоянието си, тя съобщава за събитието на родителя, а родителят решава как да промени състоянието.

Предимства на UDF: предвидимост — състоянието се променя само на едно място, което елиминира race conditions; проследимост — чрез стека на повикванията може да се реконструира веригата на промени; тестване — stateful логиката може да бъде изнесена в отделен клас и тествана без UI. В големи проекти UDF в комбинация с State Hoisting е де факто стандарт.

Единствен източник на истина (Single Source of Truth) — още един принцип, който придружа UDF. Всяка част от състоянието има точно един източник. Ако два компонента използват едно и също състояние, източникът трябва да е общ (на ниво ViewModel или общ родител). State Hoisting гарантира, че източникът е по-горе в йерархията и не се появява дублиране на състоянието.

Правила на State Hoisting: кога и как да повдигаме състояние

Основно правило: състоянието трябва да бъде повдигнато на най-ниското възможно ниво, достатъчно за всички компоненти, които се нуждаят от него. Ако състоянието се използва само внутрен на един компонент — оставете го локален. Ако два съседни компонента се нуждаят от едно и също състояние — повдигнете го до общия родител. Ако състоянието е необходимо на цялия екран — повдигнете го в ViewModel.

Правило за минимално повдигане предотвратява ненужната сложност. Няма смисъл да повдигате състоянието на текстово поле в ViewModel, ако то се използва само внутрен на един екран и не се запазва при повторното създаване на Activity. Използвайте rememberSaveable на нивото на родителя на екрана, а не ViewModel, за UI състояние, което трябва да оцелее при завъртане на екрана, но не е необходимо за бизнес логиката.

Кога да повдигаме в ViewModel: ако състоянието трябва да се запази при повторното създаване на Activity, ако е необходимо за няколко екрана, ако промяната на състоянието задва бизнес логика (мрежови заявки, база от данни). State Hoisting на ниво ViewModel е типичен модел в MVVM архитектурата, където UI слоят е stateless, а ViewModel е stateful.

    // ❌ Лошо: компонентът притежава собствено състояние
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Добре: State Hoisting — състоянието в родителя
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Използване: родителят притежава състояние
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

Примери за State Hoisting в реални компоненти

Разгледете екрана за вход с два полета (email, парола) и бутон. И трите компонента получават състояние чрез State Hoisting: email и паролата се управляват от родителя, бутонът получава enabled статус като стойност.

    // State Hoisting на ниво екран
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // Email поле — State Hoisting чрез лямбда
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // Поле за парола — подобно
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Бутон — получава само enabled (read-only)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Stateless компонент: получава email + callback
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("Email") },
        singleLine = true
    )
}

// Stateless компонент за бутон
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Вход")
    }
}

EmailField и PasswordField — напълно stateless. Те могат да се използват повторно на всякаква екрана, свързани с всякакъв източник на данни. LoginButton получава enabled като read-only — това е друга форма на State Hoisting, при която състоянието не се повдига (бутонът не може да се активира сам), а се предава готов. Този подход осигурява максимална гъвкост при минимална връзка между компонентите.

State Hoisting срещу локално състояние: критерии за избор

Не всяко състояние трябва да се повдига. Локалното състояние (State внутрен на Composable) е оправдано, когато: данните са необходими само внутрен на един компонент, не засягат съседните елементи, не трябва да оцелеят при рекомпозиция на определен раздел. Например, състояние на анимацията, фокус на полето за въвеждане, текуща позиция на превъртане — разумно е да се държат локално.

Кога State Hoisting е необходимо: състоянието се използва от няколко подчинени компоненти; промяната в един подчинен трябва да се отрази в друг; трябва да тествате логиката на промяна на състоянието отделно от UI; състоянието трябва да се запази при повторното създаване на Activity. В тези случаи локалното състояние създава дублиране и непълности на данните.

Хибриден подход: държете минималното състояние локално, повдигнете останалото. Правилото на Compose: „повдигайте състоянието толкова високо, колкото е необходимо, и толкова ниско, колкото е възможно“. На практика това означава да започнете с локален remember, и само когато възникне нужда от достъп от друг компонент — да повдигнете нивото. Не правете State Hoisting превентивно — това усложнява кода без необходимост.