Shared: una referencia que sigue comportándose como estado

Un ingeniero que llega a @Shared desde la ortodoxia funcional siente de inmediato que algo huele mal: acaban de meter una referencia mutable en el corazón de una arquitectura cuyo argumento de venta era que no había referencias mutables. La sospecha es sana y merece una respuesta precisa, porque de ella depende que uses la herramienta con criterio o con miedo. La respuesta corta es que @Shared no es una referencia cualquiera, sino una indirección instrumentada: mantiene la unicidad del dato, conserva las propiedades observables del estado y —esto es lo que la separa de un singleton— guarda memoria de su propio pasado para que un test pueda seguir afirmando, línea a línea, qué cambió y quién lo cambió. Compartir sin esconder es una posición defendible; esta lección explica cómo se sostiene técnicamente.

Declarar y entregar

La declaración es un property wrapper sobre un campo normal del estado, y la entrega es el paso del valor proyectado en el inicializador del hijo. Nada más.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {
    @Shared var usuario: Usuario     // la caja, no una copia
    var editando = false
  }
}

@Reducer
struct Ajustes {
  @ObservableState
  struct State: Equatable {
    @Shared var usuario: Usuario     // la misma caja
    var notificacionesActivas = true
  }
}

@Reducer
struct App {
  @ObservableState
  struct State: Equatable {
    @Shared var usuario: Usuario
    var perfil: Perfil.State
    var ajustes: Ajustes.State

    init(usuario: Usuario) {
      let compartido = Shared(value: usuario)
      self._usuario = compartido
      self.perfil = Perfil.State(usuario: compartido)
      self.ajustes = Ajustes.State(usuario: compartido)
    }
  }
}

Hay tres formas de nombrar lo mismo y conviene fijarlas desde el principio, porque toda la ergonomía del tipo depende de distinguirlas. usuario es el valor envuelto: se lee como cualquier campo y devuelve el Usuario actual. $usuario es el valor proyectado: es el Shared en sí, la caja, y es lo que se pasa a otra feature para que comparta. Y _usuario es el almacenamiento del wrapper, que solo aparece cuando escribes un inicializador a mano. Un hijo que recibe $usuario no recibe un Usuario: recibe el derecho a mirar y modificar exactamente la misma celda que mira su padre.

El valor proyectado admite además acceso por miembro dinámico, lo que permite compartir una parte en lugar del todo. Si una feature solo necesita el nombre, $usuario.nombre produce un Shared de esa propiedad, apoyado sobre la misma caja de origen, y esa feature no llega a ver el resto del perfil. Es la contrapartida de scope para el estado compartido: rebanar sin duplicar.

Qué se copia cuando se copia

Aquí está el nudo conceptual. Perfil.State sigue siendo una estructura y sigue teniendo semántica de valor: copiarla produce una estructura independiente cuyos campos normales —editando— son suyos y de nadie más. Lo que ocurre con el campo compartido es que lo que se copia es la referencia a la caja, no su contenido. Dos copias del State tienen dos booleanos distintos y un único Usuario, y esa asimetría es intencionada, porque es exactamente el modelo del dominio: lo local es local y lo único es único.

var a = Perfil.State(usuario: $usuario)
var b = a                       // copia de la estructura

b.editando = true               // solo afecta a b
b.$usuario.withLock { $0.nombre = "Ada" }
a.usuario.nombre                // "Ada": la caja es la misma

De ahí se sigue todo lo demás. La conformidad a Equatable se sintetiza sin problema porque Shared es comparable cuando lo es su contenido, y compara valores envueltos: dos estados que apuntan a la misma caja son iguales en ese campo por construcción, y dos que apuntan a cajas distintas con el mismo contenido también lo son. La observación funciona porque el acceso al valor envuelto se registra igual que el de cualquier propiedad observada, de modo que una vista que lee store.usuario.nombre se invalida cuando ese nombre cambia, venga el cambio de su propio reducer o del de otra feature al otro extremo del árbol. Y la composición no se entera de nada: Scope, ifLet y forEach siguen operando sobre estructuras, sin saber ni necesitar saber que uno de los campos es una caja.

Merece la pena nombrar lo que aquí se sacrifica, porque no es cero. La afirmación el estado de esta feature solo cambia cuando esta feature procesa una acción deja de ser cierta en el momento en que aparece un @Shared. Sigue siendo cierta para todos los demás campos, y la escritura sigue estando restringida a una operación explícita que la lección siguiente estudia en detalle, pero la propiedad global se ha debilitado a cambio de la unicidad. Ese intercambio es el asunto de la quinta lección; por ahora basta con saber que existe y que está localizado en los campos que llevan la marca.

Cómo sigue siendo testeable

La objeción seria contra el estado compartido no es estética sino metodológica: si un dato puede cambiar desde fuera de la feature, ¿cómo puede un TestStore seguir siendo exhaustivo? La respuesta es que Shared no guarda solo su valor actual, sino también una instantánea del valor que tenía en el último punto de comprobación. El TestStore compara contra esa instantánea, no contra un estado anterior que ya no existe, y con eso recupera el diff exacto.

@Test
func editarNombre() async {
  let usuario = Shared(value: Usuario(nombre: "Ada"))
  let store = TestStore(initialState: Perfil.State(usuario: usuario)) {
    Perfil()
  }

  await store.send(.nombreCambiado("Grace")) {
    $0.$usuario.withLock { $0.nombre = "Grace" }
  }
}

La aserción se escribe con la misma forma que la escritura real, y su ausencia se castiga igual que la de cualquier otro campo: si el reducer toca el usuario y el test no lo declara, la prueba falla con un diff que señala exactamente la diferencia. La simetría es total con el estado normal, y esa simetría es la prueba de que la herramienta está bien construida: no hay una segunda gramática de testing para el estado compartido, hay la misma con un acceso más.

Hay además una consecuencia práctica que conviene aprovechar desde el primer día. Como la caja se construye fuera del store y se pasa a la feature, un test puede crearla, entregarla y después inspeccionarla directamente para comprobar el efecto lateral que la feature ha tenido sobre el mundo compartido, sin necesidad de mirar dentro del estado del store:

let sesion = Shared(value: Sesion(usuario: nil))
let store = TestStore(initialState: Autenticacion.State(sesion: sesion)) {
  Autenticacion()
}

await store.send(.entrarPulsado)
await store.receive(\.respuestaLogin.success)
#expect(sesion.wrappedValue.usuario?.nombre == "Ada")

Esa capacidad de sostener la caja desde el test es el reflejo exacto de lo que ocurre en producción, donde quien la sostiene es el padre. Y explica por qué la forma recomendada de crear estado compartido es Shared(value:) y no una clave global: cuando la caja se recibe, el test puede fabricarla; cuando se conjura por una cadena de texto, el test tiene que confiar en que el almacén subyacente esté limpio.

flowchart LR
P[App State] -->|pasa el valor proyectado| A[Perfil State]
P -->|pasa el valor proyectado| B[Ajustes State]
A --> C[Caja compartida con Usuario]
B --> C
C --> S[Instantanea para el TestStore]
A --> L1[Campos locales propios]
B --> L2[Campos locales propios]
style C fill:#a6e3a1,color:#11111b