Unidirectional Data Flow — wat is het, UDF in Android en iOS

Wat is Unidirectional Data Flow?

Unidirectional Data Flow (UDF) — een architectuurpatroon waarbij gegevens in één richting langs een gesloten cyclus bewegen, waarbij feedback tussen View en Model wordt uitgesloten. In tegenstelling tot Two-Way Binding, waar een verandering in de UI onmiddellijk het model bijwerkt, vereist UDF een expliciete actie (Intent, Event, Action) voor elke toestandsverandering. Dit maakt de gegevensstroom volledig voorspelbaar: op elk moment kan worden bepaald welke actie tot de huidige toestand heeft geleid.

Het UDF-concept komt uit webframeworks — Redux (JavaScript, 2015) en Elm (2012) — en is aangepast voor mobiele ontwikkeling. Volgens Google I/O 2024 is UDF de aanbevolen architectuur geworden voor Jetpack Compose, ter vervanging van klassieke MVVM met LiveData. Op iOS wordt een vergelijkbare aanpak geïmplementeerd in The Composable Architecture (TCA) van Point-Free, die door meer dan 15% van iOS-ontwikkelaars wordt gebruikt volgens de Swift Community-enquête (2024).

Het belangrijkste voordeel van UDF — Single Source of Truth (SSOT): de volledige applicatiestatus wordt op één plek opgeslagen en gewijzigd via strikt gedefinieerde bewerkingen. Dit vereenvoudigt het debuggen, testen en reproduceren van bugs, omdat elke toestandsverandering wordt geregistreerd en kan worden gereproduceerd door dezelfde Intent opnieuw te verzenden.

Hoe werkt UDF: cyclus State → View → Intent → Reducer

De basis-UDF-cyclus bestaat uit vier stappen: State (huidige toestand) wordt weergegeven in View; de gebruiker voert een actie uit die wordt omgezet in Intent (bedoeling); Intent wordt verwerkt in Reducer (een pure functie), die een nieuwe State creëert; de nieuwe toestand wordt naar View gestuurd voor hertekenen. Deze cyclus herhaalt zich bij elke gebruikers- of systeemgebeurtenis.

Elk element van de cyclus heeft een strikte verantwoordelijkheid: State — een onveranderlijk (immutable) object dat de schermtoestand op een bepaald moment beschrijft; View — een functie die State weergeeft; Intent — een waarde die de bedoeling van de gebruiker beschrijft (bijv. LoginIntent.Submit); Reducer — een pure functie zonder bijwerkingen, die huidige State en Intent ontvangt en een nieuwe State retourneert. Bijwerkingen (netwerkverzoeken, databases) worden verplaatst naar een aparte Middleware- of Effect-laag.

Volgens het artikel Google Android Architecture (2024) is de zuiverheid van Reducer een cruciale vereiste: als Reducer een netwerkoproep of databaseschrijfbewerking bevat, wordt het testen en debuggen van de gegevensstroom onmogelijk. Alle bijwerkingen moeten worden uitgevoerd in de ViewModel-coroutine of Swift Task vóór het aanroepen van Reducer, en het resultaat moet worden verzonden als een nieuwe Intent.

UDF in Android: ViewModel + StateFlow + Intent

In Android is de implementatie van UDF gebaseerd op drie Jetpack-componenten: ViewModel beheert de levenscyclus, StateFlow zorgt voor een reactieve stroom van toestanden, Intent (sealed class) beschrijft alle mogelijke gebruikersacties. View abonneert zich op StateFlow via collectAsState() in Compose of observe() in het View-systeem.

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) }
    )
}

Het voorbeeld toont de volledige UDF-cyclus in Android: LoginIntent beschrijft alle mogelijke acties (e-mail wijzigen, wachtwoord wijzigen, formulier verzenden), LoginState — de onveranderlijke toestand, LoginViewModel verwerkt Intent en werkt StateFlow bij, en het Compose-scherm abonneert zich op state via collectAsState(). Elke toestandsverandering is het resultaat van de verwerking van een specifieke Intent, wat de gegevensstroom volledig transparant maakt.

UDF in iOS: TCA en Observable-patroon

Op iOS wordt UDF geïmplementeerd via The Composable Architecture (TCA) van Point-Free of het native Observable-patroon met iOS 17+. TCA biedt een kant-en-klare cyclus State + Action + Reducer + Store, waarbij Store de enige bron van waarheid is en View zich abonneert op wijzigingen via @Observable of 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("Inloggen") { viewStore.send(.submit) }
            }
        }
    }
}

De reduceerder loginReducer — een pure functie: voert geen netwerkverzoeken direct uit, maar retourneert een Effect dat door de TCA-omgeving wordt uitgevoerd. Dit maakt het mogelijk om de reduceerder geïsoleerd te testen, waarbij effecten in tests worden vervangen. View abonneert zich via WithViewStore op wijzigingen in Store en verzendt Action via send(). TCA beheert automatisch het annuleren van effecten bij het vernietigen van Store, waardoor geheugenlekken worden voorkomen.

UDF versus MVVM: wat is het verschil?

MVVM en UDF worden vaak verward, maar er is een fundamenteel verschil tussen beide. MVVM is een structureel patroon dat code verdeelt in drie lagen (Model, View, ViewModel), maar niet de richting van de gegevensstroom bepaalt. UDF is een gedragspatroon dat beschrijft hoe gegevens binnen deze structuur bewegen. In MVVM met LiveData kan zowel bidirectionele binding als unidirectionele stroom voorkomen — UDF voegt strikte regels voor Intent-verwerking toe aan MVVM.

Volgens de Android Developers-documentatie (2024) is de aanbevolen architectuur voor Compose UDF binnen MVVM: ViewModel slaat State op en verwerkt Intent, View abonneert zich op State en verzendt Intent. Klassieke MVVM met Two-Way Binding via DataBinding wordt door Google alleen aanbevolen voor eenvoudige schermen zonder bedrijfslogica. Voor Jetpack Compose is het belangrijkste scenario UDF met expliciete gebeurtenisafhandeling.

Vergelijkingstabel:

Veelgemaakte fouten bij het implementeren van UDF

De meest voorkomende fout — bijwerkingen binnen Reducer. Ontwikkelaars die gewend zijn aan MVVM plaatsen netwerkverzoeken direct in de Intent-handler, waardoor Reducer een onzuivere functie wordt en de testbaarheid wordt verbroken. Alle effecten moeten worden geretourneerd als waarde (Effect / SideEffect) en worden uitgevoerd door de framework-infrastructuur. In Android worden hiervoor coroutines in ViewModel gebruikt, in TCA — Effect.run.

De tweede fout — te gedetailleerde Intent. Elke toetsaanslag, schuifregelaarbeweging en tekstwijziging genereert een aparte Intent. Voor invoervelden is dit overdreven — in dergelijke gevallen is het acceptabel om Binding met unidirectionele stroom binnen het formulier te gebruiken (lokale toestand), en een globale Intent alleen te verzenden bij significante acties (verzenden, navigatie).

De derde fout — geen annuleringsafhandeling van effecten. Als de gebruiker het scherm verlaat en de coroutine of Task blijft uitvoeren, kan het resultaat worden toegepast op een reeds vernietigde View. Gebruik in Android viewModelScope.cancel() of takeWhileActive(); in TCA worden effecten automatisch geannuleerd bij vernietiging van Store. Volgens Google Issue Tracker (2024) behoren lekken van onvoltooide coroutines tot de top-5 oorzaken van crashes in Compose-applicaties.