Semántica de valor: por qué TCA vive de structs y enums

Hay una pregunta que conviene hacerse antes de escribir el primer reducer: ¿por qué TCA insiste en que el State sea un struct y la Action un enum, cuando el mundo de Cocoa lleva décadas modelando pantallas con clases? La respuesta no es estilística ni una preferencia funcional heredada de Elm: es que la semántica de valor cambia quién puede mutar qué y cuándo, y ese cambio es la condición técnica de todo lo que la arquitectura promete después. Con un struct, una copia del estado es un estado independiente que nadie puede alterar a tus espaldas; con una class, cualquiera que tenga la referencia puede escribir en él desde otro hilo, en otro archivo, tres capas más abajo. Esta lección examina qué garantiza exactamente cada semántica, por qué copiar sale mucho más barato de lo que temes, y qué se pierde —y por qué no importa— al renunciar a la identidad.

Referencia contra valor: quién puede mutar qué

Swift parte sus tipos en dos familias con reglas de asignación opuestas. class y actor tienen semántica de referencia: asignar copia el puntero, no el contenido, así que dos nombres pueden apuntar al mismo objeto. struct, enum y las tuplas tienen semántica de valor: asignar copia el contenido, y a partir de ese instante las dos variables son historias separadas.

final class ContadorClase {
  var cuenta = 0
}

struct ContadorValor {
  var cuenta = 0
}

let a = ContadorClase()
let b = a
b.cuenta = 42
// a.cuenta también vale 42: a y b nombran el mismo objeto

var c = ContadorValor()
var d = c
d.cuenta = 42
// c.cuenta sigue valiendo 0: d es una copia independiente

La diferencia se llama aliasing, y es la raíz de una familia entera de bugs. Con la clase, a cambió sin que ninguna línea de código mencionara a; el causante estaba en otra parte del programa y no dejó rastro en el sitio donde se manifiesta el síntoma. Fíjate además en el let b = a: la constante no protege nada, porque lo constante es el puntero, no el objeto al que apunta. La inmutabilidad de una referencia es cosmética.

El patrón se vuelve endémico en cuanto una app crece, y casi siempre por una decisión razonable: compartir el modelo para que dos pantallas no se desincronicen.

final class ModeloUsuario {
  var nombre = "Ada"
}

let compartido = ModeloUsuario()
let perfil = PantallaPerfil(modelo: compartido)
let ajustes = PantallaAjustes(modelo: compartido)

ajustes.guardarNombre("Grace")   // perfil también lo ve, sin enterarse

El día que funciona parece elegante; el día que falla no hay forma de reconstruir qué escribió qué. La pregunta quién cambió este campo no tiene respuesta local, porque cualquiera con la referencia es sospechoso, y el conjunto de sospechosos crece con cada inyección. En un sistema de referencias compartidas, la respuesta correcta a esa pregunta es siempre el programa entero.

Lleva esto al State de una feature. Si fuera una clase, la vista podría escribirlo, un servicio en segundo plano también, y el reducer sería apenas uno de varios autores posibles. Al ser una struct, la premisa de la arquitectura se vuelve verificable por construcción: el estado solo cambia dentro del reducer y solo como respuesta a una acción, porque nadie más tiene un asa que apunte a la misma memoria. El flujo unidireccional deja de ser una convención que el equipo respeta por disciplina y pasa a ser una propiedad que el lenguaje impone.

Copy-on-write: el coste que casi nunca existe

La objeción llega enseguida: si el estado de la app entera es una struct, ¿no estamos copiando un objeto enorme en cada acción? La respuesta es no, y el motivo tiene nombre: copy-on-write. Los contenedores de la biblioteca estándar —Array, Dictionary, Set, String— y también el IdentifiedArray de Point-Free guardan sus elementos en un búfer con recuento de referencias. Copiar el valor copia el puntero al búfer e incrementa el recuento; el búfer solo se duplica de verdad cuando alguien intenta escribir mientras el recuento es mayor que uno.

@ObservableState
struct State: Equatable {
  var items: IdentifiedArrayOf<Item> = []   // el buffer se comparte hasta escribir
  var filtro = ""
  var seleccion: Item.ID?
}

De ahí que una copia de esa struct cueste, en la práctica, copiar unos pocos campos escalares y ajustar un par de recuentos: trabajo proporcional al número de propiedades, no al de elementos. La mutación sí paga la copia real del búfer, pero solo la primera vez y solo si el valor está compartido en ese momento; dentro del reducer, donde el estado se muta en exclusiva, la escritura suele ocurrir en sitio sin copia alguna.

Conviene añadir el otro coste que la semántica de valor introduce y que se olvida al hablar solo de copias: la comparación. El State conforma a Equatable porque el TestStore necesita diferenciar dos instantáneas y la observación necesita saber si algo cambió, y comparar dos valores grandes recorre sus campos. También aquí el copy-on-write ayuda más de lo esperado, porque comparar dos colecciones que aún comparten búfer puede resolverse comprobando que el puntero es el mismo. La regla operativa que se deriva es sencilla y vale para todo el nivel: en el estado van datos, identificadores y banderas; los objetos pesados y las entidades con ciclo de vida propio viven detrás de una dependencia.

inout no es una fuga: es una ecuación con buena ergonomía

Al ver state.cuenta += 1 dentro de un reducer, la intuición sugiere que ahí hay mutación compartida. No la hay. El parámetro está marcado inout, y inout no es un puntero al estilo de C: es un préstamo exclusivo. El compilador aplica la ley de exclusividad —el mismo valor no puede estar accesible por dos caminos mientras dura el préstamo— y el efecto observable es copiar dentro, escribir, copiar fuera. Nadie más ve el valor a medio mutar.

func reduce(into state: inout State, action: Action) -> Effect<Action> {
  switch action {
  case .incrementar:
    state.cuenta += 1
    return .none
  }
}

Por eso (inout State, Action) -> Effect<Action> es, semánticamente, la misma función que (State, Action) -> (State, Effect<Action>), escrita de una forma que evita reconstruir a mano una struct de veinte campos para cambiar uno. Es azúcar sintáctico sobre una transformación pura, no una grieta en la pureza. Y trae una consecuencia práctica que reaparecerá al hablar de efectos: inout no puede escapar de la llamada, así que dentro de un Effect.run no tienes acceso al estado. Debes capturar por valor lo que necesites —[id = state.id]— y devolver el resto como acciones. Esa incomodidad aparente es la frontera entre lógica y mundo, dibujada por el sistema de tipos.

Lo que se gana renunciando a la identidad

Un valor no tiene identidad: dos struct con los mismos campos son indistinguibles, y no existe un === que aplicarles. Esa pérdida es exactamente lo que habilita el resto de la arquitectura.

Cuando de verdad hace falta identidad —distinguir dos filas idénticas de una lista— TCA no la recupera con punteros: la modela como dato, con Identifiable y un ID estable dentro del propio valor. La identidad deja de ser una dirección de memoria accidental y pasa a ser una propiedad del dominio, comparable, serializable y testeable.

flowchart TD
subgraph Referencia
  R1[variable a] --> OBJ[objeto compartido]
  R2[variable b] --> OBJ
  OBJ --> M[cualquiera muta y nadie se entera]
end
subgraph Valor
  V1[copia a] --> E1[estado independiente]
  V2[copia b] --> E2[estado independiente]
  E1 --> RED[solo el reducer escribe]
  E2 --> RED
end
style OBJ fill:#f38ba8,color:#11111b
style RED fill:#a6e3a1,color:#11111b