Unidirectional Data Flow — co to je, UDF v Android a iOS

Co je Unidirectional Data Flow?

Unidirectional Data Flow (UDF) — architektonický vzor, ve kterém se data pohybují jedním směrem podél uzavřeného cyklu, čímž se vylučuje zpětná vazba mezi View a Modelem. Na rozdíl od Two-Way Binding, kde změna v UI okamžitě aktualizuje model, UDF vyžaduje explicitní akci (Intent, Event, Action) pro každou změnu stavu. To činí tok dat zcela předvídatelným: v každém okamžiku lze určit, která akce vedla k aktuálnímu stavu.

Koncepce UDF pochází z webových frameworků — Redux (JavaScript, 2015) a Elm (2012) — a byla adaptována pro mobilní vývoj. Podle Google I/O 2024 se UDF stal doporučenou architekturou pro Jetpack Compose a nahrazuje klasické MVVM s LiveData. Na iOS je podobný přístup implementován v The Composable Architecture (TCA) od Point-Free, kterou používá více než 15 % iOS vývojářů podle průzkumu Swift Community (2024).

Hlavní výhoda UDF — Single Source of Truth (SSOT): celý stav aplikace je uložen na jednom místě a měněn prostřednictvím striktně definovaných operací. To zjednodušuje ladění, testování a reprodukci chyb, protože každá změna stavu je zaznamenána a může být reprodukována opětovným odesláním stejných Intent.

Jak funguje UDF: cyklus State → View → Intent → Reducer

Základní cyklus UDF se skládá ze čtyř kroků: State (aktuální stav) je zobrazen v View; uživatel provede akci, která se přemění na Intent (záměr); Intent je zpracován v Reducer (čistá funkce), který vytvoří nový State; nový stav je předán View k překreslení. Tento cyklus se opakuje při každé uživatelské nebo systémové události.

Každý prvek cyklu má striktní odpovědnost: State — neměnný (immutable) objekt popisující stav obrazovky v daném okamžiku; View — funkce zobrazující State; Intent — hodnota popisující záměr uživatele (např. LoginIntent.Submit); Reducer — čistá funkce bez vedlejších účinků, přijímající aktuální State a Intent a vracející nový State. Vedlejší účinky (síťové požadavky, databáze) jsou přeneseny do samostatné vrstvy Middleware nebo Effect.

Podle článku Google Android Architecture (2024) je čistota Reducer klíčovým požadavkem: pokud Reducer obsahuje síťové volání nebo zápis do databáze, testování a ladění toku dat je nemožné. Všechny vedlejší účinky musí být provedeny v korutině ViewModel nebo Swift Task před voláním Reducer a výsledek odeslán jako nový Intent.

UDF v Androidu: ViewModel + StateFlow + Intent

V Androidu je implementace UDF založena na třech komponentách Jetpack: ViewModel spravuje životní cyklus, StateFlow poskytuje reaktivní tok stavů, Intent (sealed class) popisuje všechny možné akce uživatele. View se přihlásí k odběru StateFlow pomocí collectAsState() v Compose nebo observe() v systému 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) }
    )
}

Příklad demonstruje úplný cyklus UDF v Androidu: LoginIntent popisuje všechny možné akce (změna emailu, hesla, odeslání formuláře), LoginState — neměnný stav, LoginViewModel zpracovává Intent a aktualizuje StateFlow, a obrazovka Compose se přihlásí k odběru state pomocí collectAsState(). Každá změna stavu je výsledkem zpracování konkrétního Intent, což činí tok dat zcela transparentním.

UDF v iOS: TCA a Observable vzor

Na iOS je UDF implementován prostřednictvím The Composable Architecture (TCA) od Point-Free nebo nativního Observable vzoru od iOS 17+. TCA poskytuje hotový cyklus State + Action + Reducer + Store, kde Store je jediným zdrojem pravdy a View se přihlásí k odběru změn pomocí @Observable nebo 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("Přihlásit se") { viewStore.send(.submit) }
            }
        }
    }
}

Reduktor loginReducer — čistá funkce: neprovádí síťové požadavky přímo, ale vrací Effect, který bude proveden prostředím TCA. To umožňuje testovat reduktor izolovaně a nahrazovat efekty v testech. View se pomocí WithViewStore přihlásí k odběru změn Store a odesílá Action pomocí send(). TCA automaticky spravuje zrušení efektů při zničení Store, čímž předchází únikům paměti.

UDF versus MVVM: jaký je rozdíl?

MVVM a UDF jsou často zaměňovány, ale je mezi nimi zásadní rozdíl. MVVM je strukturální vzor, který rozděluje kód do tří vrstev (Model, View, ViewModel), ale neurčuje směr toku dat. UDF je vzor chování, který popisuje, jak se data pohybují uvnitř této struktury. V MVVM s LiveData může existovat jak obousměrné vázání, tak jednosměrný tok — UDF přidává k MVVM přísná pravidla zpracování Intent.

Podle dokumentace Android Developers (2024) je doporučenou architekturou pro Compose UDF uvnitř MVVM: ViewModel ukládá State a zpracovává Intent, View se přihlásí k odběru State a odesílá Intent. Klasické MVVM s Two-Way Binding přes DataBinding Google doporučuje pouze pro jednoduché obrazovky bez obchodní logiky. Pro Jetpack Compose je hlavním scénářem UDF s explicitním zpracováním událostí.

Srovnávací tabulka:

Typické chyby při zavádění UDF

Nejčastější chyba — vedlejší účinky uvnitř Reducer. Vývojáři zvyklí na MVVM umísťují síťové požadavky přímo do obsluhy Intent, což činí Reducer nečistou funkcí a narušuje testovatelnost. Všechny efekty musí být vráceny jako hodnota (Effect / SideEffect) a provedeny infrastrukturou frameworku. V Androidu se k tomu používají korutiny ve ViewModel, v TCA — Effect.run.

Druhá chyba — příliš podrobné Intent. Každé stisknutí klávesy, pohyb posuvníku a změna textu generuje samostatný Intent. Pro vstupní pole je to nadbytečné — v takových případech je přijatelné použít Binding s jednosměrným tokem uvnitř formuláře (lokální stav) a globální Intent odesílat pouze při významných akcích (odeslání, navigace).

Třetí chyba — absence zpracování zrušení efektů. Pokud uživatel opustí obrazovku a korutina nebo Task pokračuje v provádění, výsledek může být aplikován na již zničené View. V Androidu použijte viewModelScope.cancel() nebo takeWhileActive(); v TCA jsou efekty automaticky zrušeny při zničení Store. Podle Google Issue Tracker (2024) patří úniky z nedokončených korutin mezi top-5 příčin pádů aplikací Compose.