Su herencia: de Redux y Elm a Swift

Ninguna de las buenas ideas de TCA es suya. El flujo unidireccional viene de Elm; el store único y el reducer vienen de Redux; la separación entre describir un cambio y ejecutarlo es tan vieja como la programación funcional. Lo que hace TCA no es inventar, sino traducir: toma un patrón probado durante una década en la web y lo reescribe en Swift, aprovechando dos rasgos que ni Elm ni JavaScript tenían a la vez —los tipos algebraicos y la semántica de valor—. Esta lección recorre esa herencia con nombre y apellido, porque entender de dónde sale cada pieza es entender por qué tiene la forma que tiene, y por qué la versión Swift es, en varios aspectos, más rigurosa que sus ancestros.

Lo que hereda de Elm

Elm, el lenguaje funcional para la web, propuso a mediados de la década pasada un patrón tan limpio que acabó llamándose simplemente The Elm Architecture. Son tres piezas: un Model que contiene todo el estado, un Message que describe cada cosa que puede pasar, y una función update que, dado un mensaje y el modelo actual, devuelve el modelo siguiente. La clave es que update es pura: no muta nada del mundo, solo calcula un valor nuevo a partir de los que recibe. Los efectos —peticiones de red, temporizadores— no se ejecutan dentro de update, sino que se devuelven como una descripción que el runtime de Elm interpreta después.

TCA copia ese esqueleto casi punto por punto. El Model de Elm es el State de TCA; el Message es el Action; la función update es el Reducer; y la idea de devolver los efectos en vez de ejecutarlos es el Effect. Si conoces Elm, ya conoces la forma de TCA; solo cambia el vocabulario y el lenguaje anfitrión. Esa deuda es explícita: Point-Free ha citado a Elm como inspiración directa en incontables ocasiones.

Lo que hereda de Redux

Redux llevó la arquitectura de Elm al ecosistema de JavaScript y le dio el vocabulario que hoy es común. De Redux, TCA toma tres compromisos. El primero es el store único: una sola fuente de verdad que sostiene el estado de la aplicación, frente a un estado repartido en mil objetos. El segundo es la acción como dato plano: un cambio no se pide llamando a un método, se describe creando un valor que dice qué pasó, y ese valor se puede registrar, inspeccionar y reproducir. El tercero es el reducer como transformación pura: una función que recibe el estado y la acción y devuelve el estado siguiente, sin efectos ocultos.

// La firma conceptual es la misma de Redux, escrita en Swift:
// (inout State, Action) -> Effect<Action>
var body: some ReducerOf<Self> {
  Reduce { state, action in
    switch action {
    case .botonMasPulsado:
      state.cuenta += 1
      return .none          // sin efecto: solo cambia el estado
    case .respuestaNumero(let n):
      state.cuenta = n
      return .none
    }
  }
}

Hay una diferencia de forma que merece atención. En Redux, el reducer recibe el estado y devuelve una copia nueva —(state, action) => newState—. En TCA, el reducer recibe el estado como inout y lo muta en el sitio —(inout State, Action) -> Effect—. Parece una traición a la pureza, pero no lo es: gracias a la semántica de valor de Swift, mutar un inout struct es indistinguible de devolver una copia modificada, y el compilador garantiza que nadie más ve esa mutación a medias. Se gana la ergonomía de escribir state.cuenta += 1 sin perder la garantía de que el reducer es una función pura del estado y la acción.

Lo que aporta Swift

Aquí es donde la traducción supera al original. Redux vive en JavaScript, un lenguaje sin tipos, donde una acción es un objeto con una cadena en el campo type y el reducer es un switch sobre esa cadena que el lenguaje no comprueba. Si te olvidas de un caso, nada te avisa. TCA vive en Swift, y modela Action como un enum: un tipo algebraico cerrado cuyos casos el compilador conoce. El switch del Reducer sobre ese enum es exhaustivo por obligación del lenguaje —si añades un caso y olvidas manejarlo, el código no compila—. La misma disciplina que Redux pedía por convención, Swift la exige por tipo.

// Action es un enum: cada evento posible es un caso, y el switch debe cubrirlos todos.
enum Action: Equatable {
  case aparecer
  case botonMasPulsado
  case respuestaNumero(Int)
  case fallo(String)
}

El segundo regalo de Swift es la capacidad de hacer irrepresentables los estados imposibles. Con struct para agrupar y enum para las alternativas excluyentes, el State puede diseñarse de modo que las combinaciones ilegales ni siquiera se puedan escribir. En lugar de tener a la vez cargando: Bool, datos: [Item]? y error: String? —que permite el absurdo de estar cargando y con error al mismo tiempo—, se modela un enum con casos cargando, cargado([Item]) y fallo(String), y el compilador prohíbe el estado imposible. Es la lección del Nivel 9 aplicada a la arquitectura entera.

flowchart TD
ELM[Elm: Model Message update] --> TCA[TCA: State Action Reducer Effect]
REDUX[Redux: store accion reducer] --> TCA
SWIFT[Swift: enum struct valor semantico] --> TCA
TCA --> R[flujo unidireccional con tipos fuertes]
style TCA fill:#cba6f7,color:#11111b
style ELM fill:#89b4fa,color:#11111b
style REDUX fill:#89b4fa,color:#11111b
style SWIFT fill:#f9e2af,color:#11111b
style R fill:#a6e3a1,color:#11111b