Unidirectional Data Flow — какво е това, UDF в Android и iOS

Какво е Unidirectional Data Flow?

Unidirectional Data Flow (UDF) — архитектурен модел, при който данните се движат в една посока по затворен цикъл, изключвайки обратната връзка между View и Model. За разлика от Two-Way Binding, където промяна в UI незабавно актуализира модела, UDF изисква изрично действие (Intent, Event, Action) за всяка промяна на състоянието. Това прави потока от данни напълно предвидим: във всеки момент може да се определи кое действие е довело до текущото състояние.

Концепцията на UDF идва от уеб рамки — Redux (JavaScript, 2015) и Elm (2012) — и е адаптирана за мобилно развитие. Според Google I/O 2024, UDF се превърна в препоръчителната архитектура за Jetpack Compose, измествайки класическия MVVM с LiveData. На iOS подобен подход е имплементиран в The Composable Architecture (TCA) от Point-Free, който се използва от над 15% от iOS разработчиците според проучването Swift Community (2024).

Основното предимство на UDF — Single Source of Truth (SSOT): цялото състояние на приложението се съхранява на едно място и се променя чрез строго определени операции. Това опростява отстраняването на грешки, тестването и възпроизвеждането на бъгове, тъй като всяка промяна на състоянието се записва и може да бъде възпроизведена чрез повторно изпращане на същите Intent.

Как работи UDF: цикъл State → View → Intent → Reducer

Основният цикъл на UDF се състои от четири стъпки: State (текущо състояние) се показва в View; потребителят извършва действие, което се превръща в Intent (намерение); Intent се обработва в Reducer (чиста функция), която създава ново State; новото състояние се предава на View за прерисуване. Този цикъл се повтаря при всяко потребителско или системно събитие.

Всеки елемент от цикъла има строга отговорност: State — неизменим (immutable) обект, описващ състоянието на екрана в даден момент; View — функция, показваща State; Intent — стойност, описваща намерението на потребителя (напр. LoginIntent.Submit); Reducer — чиста функция без странични ефекти, приемаща текущото State и Intent и връщаща ново State. Страничните ефекти (мрежови заявки, база данни) се изнасят в отделен слой Middleware или Effect.

Според статията Google Android Architecture (2024), чистотата на Reducer е ключово изискване: ако Reducer съдържа мрежово повикване или запис в база данни, тестването и отстраняването на грешки в потока от данни става невъзможно. Всички странични ефекти трябва да се изпълнят в корутина на ViewModel или Swift Task преди извикването на Reducer, а резултатът да се изпрати като нов Intent.

UDF в Android: ViewModel + StateFlow + Intent

В Android имплементацията на UDF се основава на три Jetpack компонента: ViewModel управлява жизнения цикъл, StateFlow осигурява реактивен поток от състояния, Intent (sealed class) описва всички възможни действия на потребителя. View се абонира за StateFlow чрез collectAsState() в Compose или observe() в системата View.

sealed class LoginIntent {
    data object Submit : LoginIntent()
    data class UpdateEmail(val value: String) : LoginIntent()
    data class UpdatePassword(val value: String) : LoginIntent()
}

data class LoginState(
    val email: String = "",
    val password: String = "",
    val isLoading: Boolean = false,
    val error: String? = null
)

class LoginViewModel : ViewModel() {
    private val _state = MutableStateFlow(LoginState())
    val state: StateFlow<LoginState> = _state.asStateFlow()

    fun onIntent(intent: LoginIntent) {
        when (intent) {
            is LoginIntent.UpdateEmail -> {
                _state.update { it.copy(email = intent.value) }
            }
            is LoginIntent.UpdatePassword -> {
                _state.update { it.copy(password = intent.value) }
            }
            is LoginIntent.Submit -> {
                _state.update { it.copy(isLoading = true, error = null) }
                loginUseCase(_state.value.email, _state.value.password)
                    .onSuccess {
                        _state.update { it.copy(isLoading = false) }
                    }
                    .onFailure { e ->
                        _state.update { it.copy(isLoading = false, error = e.message) }
                    }
            }
        }
    }
}

@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val state by viewModel.state.collectAsState()

    LoginForm(
        email = state.email,
        onEmailChange = { viewModel.onIntent(LoginIntent.UpdateEmail(it)) },
        password = state.password,
        onPasswordChange = { viewModel.onIntent(LoginIntent.UpdatePassword(it)) },
        isLoading = state.isLoading,
        onSubmit = { viewModel.onIntent(LoginIntent.Submit) }
    )
}

Примерът демонстрира пълния цикъл на UDF в Android: LoginIntent описва всички възможни действия (промяна на имейл, парола, изпращане на формуляр), LoginState — неизменимото състояние, LoginViewModel обработва Intent и актуализира StateFlow, а екранът Compose се абонира за state чрез collectAsState(). Всяка промяна на състоянието е резултат от обработката на конкретен Intent, което прави потока от данни напълно прозрачен.

UDF в iOS: TCA и Observable модел

На iOS UDF се имплементира чрез The Composable Architecture (TCA) от Point-Free или родния Observable модел с iOS 17+. TCA предоставя готов цикъл State + Action + Reducer + Store, където Store е единственият източник на истина, а View се абонира за промени чрез @Observable или ObservableObject.

struct LoginState: Equatable {
    var email = ""
    var password = ""
    var isLoading = false
    var error: String?
}

enum LoginAction {
    case emailChanged(String)
    case passwordChanged(String)
    case submit
    case loginResponse(Result<User, Error>)
}

let loginReducer = Reducer<LoginState, LoginAction> { state, action in
    switch action {
    case .emailChanged(let email):
        state.email = email
        return .none
    case .passwordChanged(let password):
        state.password = password
        return .none
    case .submit:
        state.isLoading = true
        state.error = nil
        return .run { send in
            let result = await loginUseCase(state.email, state.password)
            await send(.loginResponse(result))
        }
    case .loginResponse(.success):
        state.isLoading = false
        return .none
    case .loginResponse(.failure(let error)):
        state.isLoading = false
        state.error = error.localizedDescription
        return .none
    }
}

struct LoginView: View {
    let store: StoreOf<LoginReducer>

    var body: some View {
        WithViewStore(store, observe: { $0 }) { viewStore in
            Form {
                TextField("Email", text: viewStore.binding(get: \.email, send: { .emailChanged($0) }))
                SecureField("Password", text: viewStore.binding(get: \.password, send: { .passwordChanged($0) }))
                Button("Вход") { viewStore.send(.submit) }
            }
        }
    }
}

Редукторът loginReducer — чиста функция: не изпълнява мрежови заявки директно, а връща Effect, който ще бъде изпълнен от средата на TCA. Това позволява тестване на редуктора изолирано, като ефектите се заменят в тестовете. View чрез WithViewStore се абонира за промените в Store и изпраща Action чрез send(). TCA автоматично управлява отмяната на ефекти при унищожаване на Store, предотвратявайки изтичане на памет.

UDF срещу MVVM: каква е разликата?

MVVM и UDF често се бъркат, но между тях има фундаментална разлика. MVVM е структурен модел, който разделя кода на три слоя (Model, View, ViewModel), но не определя посоката на потока от данни. UDF е модел на поведение, който описва как данните се движат вътре в тази структура. В MVVM с LiveData може да има както двупосочно свързване, така и еднопосочен поток — UDF добавя към MVVM строги правила за обработка на Intent.

Според документацията на Android Developers (2024), препоръчителната архитектура за Compose е UDF вътре в MVVM: ViewModel съхранява State и обработва Intent, View се абонира за State и изпраща Intent. Класическият MVVM с Two-Way Binding чрез DataBinding се препоръчва от Google само за прости екрани без бизнес логика. За Jetpack Compose основният сценарий е UDF с изрична обработка на събития.

Сравнителна таблица:

Типични грешки при внедряване на UDF

Най-честата грешка — странични ефекти вътре в Reducer. Разработчици, свикнали с MVVM, поставят мрежови заявки директно в handler на Intent, което прави Reducer нечиста функция и нарушава тестваемостта. Всички ефекти трябва да бъдат върнати като стойност (Effect / SideEffect) и изпълнени от инфраструктурата на рамката. В Android за това се използват корутини в ViewModel, в TCA — Effect.run.

Втората грешка — твърде детайлизирани Intent. Всяко натискане на клавиш, движение на плъзгач и промяна на текст генерира отделен Intent. За полета за въвеждане това е прекомерно — в такива случаи е допустимо използването на Binding с еднопосочен поток вътре във формуляра (локално състояние), а глобален Intent да се изпраща само при значими действия (изпращане, навигация).

Третата грешка — липса на обработка на отмяна на ефекти. Ако потребителят напусне екрана, а корутината или Task продължава изпълнение, резултатът може да бъде приложен към вече унищожено View. В Android използвайте viewModelScope.cancel() или takeWhileActive(); в TCA ефектите се отменят автоматично при унищожаване на Store. Според Google Issue Tracker (2024), изтичанията от незавършени корутини са сред топ-5 причини за сривове на Compose приложения.