Skip to content

CONCEPT Cited by 1 source

Elm architecture

Definition

The Elm architecture (often abbreviated TEA — The Elm Architecture) is a UI programming pattern originated by the Elm programming language that decomposes any interactive application into three pieces:

  1. Model — an immutable value representing the entire application state.
  2. View — a pure function Model → UI that renders the state.
  3. Update — a pure function (Msg, Model) → Model that returns a new Model in response to events (Msg).

Data flow is unidirectional: user input produces Msg values; Update folds them into a new Model; View renders it. No view holds mutable state; no component mutates another component's state directly.

Reference: Elm guide — The Elm Architecture.

Appcraft's adoption on mobile

Appcraft — Zalando's server-driven mobile UI framework — is explicitly described as "a mobile version of the Elm architecture" (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework).

The wiring is:

  • Model: the state implied by the current server-sent screen JSON + any local UI state (scroll position, expansion toggles, …).
  • View: each Appcraft primitive (Label, Image, Layout, …) renders the current Model into the native Texture (iOS) or Litho (Android) tree.
  • Update: tap / scroll-forward / dismiss events (plus their ordered action lists from the component JSON) produce Msg values; the client dispatches them through a central Update path.

The post frames Elm as "clear separation of concerns … simplifies code maintenance and enhances predictability" — i.e. precisely the properties server-driven UI needs from its client runtime so that an arbitrary server-defined tree can be rendered and remain interactive without the client knowing anything about the domain.

Why it's a good fit for server-driven UI

SDUI clients receive arbitrary component trees from the server whose combined state is hard to predict. A unidirectional, state-as-immutable-value programming model simplifies the renderer in three ways:

  • View is derivable from state alone — no hidden per-component side-effects that would break if the server re-orders or re-replaces the tree.
  • Updates are serializable — the event → new-state transition is a pure function, easy to record / replay for bug-triage and easy to log for observability.
  • Substitutability of views — any Model can be rendered by any View function; the server can change the view tree freely without client logic needing to understand it.

Adjacent frameworks using the same shape

  • Redux (JavaScript) — explicit TEA adaptation.
  • SwiftUI / Jetpack Compose — declarative UI with explicit unidirectional state flow.
  • React with reducers — useReducer is TEA in a hook.
  • Flutter with BLoC or Redux pattern.

Seen in

Last updated · 550 distilled / 1,221 read