Escribir en estado compartido: withLock y la propagación del cambio

La primera vez que intentas escribir en un campo compartido, el compilador te para. La reacción natural es buscar el atajo que devuelva la asignación de toda la vida, y esa reacción es la que conviene resistir, porque la fricción está puesta a propósito y en el sitio exacto donde hace falta. Una caja compartida por varias features es, en Swift 6, memoria alcanzable desde más de un contexto de concurrencia; y una escritura sobre memoria compartida que no declare su sección crítica es, por definición, una carrera esperando a manifestarse. Pero la razón técnica es solo la mitad. La otra mitad es arquitectónica: withLock convierte la mutación de un dato global en un acto sintácticamente visible, imposible de confundir con la asignación inocente de un campo local, y esa visibilidad es la que permite revisar un diff y saber en qué líneas exactas el sistema toca algo que otros están mirando.

Por qué no se puede asignar

La escritura se hace siempre sobre el valor proyectado, pasando por una función que recibe el contenido como parámetro inout y lo devuelve mutado.

case .nombreCambiado(let nuevo):
  state.$usuario.withLock { $0.nombre = nuevo }
  return .none

case .planMejorado:
  state.$usuario.withLock { usuario in
    usuario.plan = .profesional
    usuario.creditos += 100          // dos campos, una sola sección crítica
  }
  return .none

Tres razones sostienen esta forma y ninguna es cosmética. La primera es la exclusión mutua: la caja es alcanzable desde cualquier hilo, así que un incremento escrito como leer, sumar y guardar puede intercalarse con otro y perder una de las dos sumas; el bloque garantiza que ese ciclo completo ocurre sin interrupciones. La segunda es la atomicidad de la transacción: cuando una operación de dominio toca dos campos que deben cambiar juntos —el plan y los créditos del ejemplo— hacerlo dentro de un mismo bloque impide que alguien observe el estado intermedio, mientras que dos asignaciones sueltas lo exponen. La tercera es la legibilidad del cambio: state.editando = true y state.$usuario.withLock se distinguen de un vistazo, y esa distinción tipográfica es lo que permite auditar un módulo entero buscando dónde se escribe algo que no es propio.

El bloque devuelve lo que devuelva su cuerpo, lo que permite leer y escribir en la misma operación sin abrir dos ventanas donde podría colarse otro escritor.

let creditosRestantes = state.$usuario.withLock { usuario -> Int in
  usuario.creditos -= coste
  return usuario.creditos
}

Y de ahí salen las reglas de higiene, que son las de cualquier sección crítica de cualquier lenguaje. El bloque debe ser corto, porque mientras dure nadie más escribe. Debe ser síncrono: no se hace trabajo asíncrono dentro, ni se llama a una dependencia que pueda bloquear, ni se espera nada. No se envía una acción desde dentro, porque eso reentraría en el sistema con el candado tomado. Y no se toca otra caja compartida dentro del bloque de la primera, porque dos secciones críticas anidadas en orden distinto en dos sitios distintos son un abrazo mortal escrito a mano.

Cómo viaja el cambio, y cómo no

Escribir en la caja hace una sola cosa: cambia el contenido de la caja. Todo lo demás se sigue de que hay features apuntando a ella, y conviene separar con cuidado lo que sí ocurre de lo que no.

Lo que sí ocurre es la invalidación de la interfaz. Cualquier vista que hubiera leído esa propiedad durante su última evaluación está registrada como dependiente, de modo que la escritura la marca como sucia y SwiftUI la reevalúa en el siguiente ciclo. Da igual dónde esté esa vista en el árbol, si pertenece a otra pestaña o si su feature ni siquiera es pariente de la que escribió: la observación va por lectura, no por parentesco. Es exactamente la propiedad que se buscaba en la primera lección, y funciona sin escribir una línea de propagación.

Lo que no ocurre es cualquier otra cosa. Ninguna acción se envía. Ningún reducer de ninguna otra feature se ejecuta. Nadie recibe una notificación que le permita reaccionar, validar, cancelar un efecto o disparar uno nuevo. Si Ajustes necesitara recalcular algo cuando el plan del usuario cambia, no hay nada en el mecanismo de @Shared que se lo diga: su reducer sigue esperando acciones propias que nadie va a enviar. Esta asimetría es la fuente de la inmensa mayoría de los errores de razonamiento con estado compartido, y merece formularse como regla: el estado compartido propaga datos, no eventos.

De la regla se sigue la práctica. Si lo que la otra feature necesita es el dato, comparte y no hagas nada más: leerá el valor nuevo la próxima vez que lo lea, que en una vista es inmediatamente. Si lo que necesita es enterarse de que ocurrió algo —para lanzar una petición, cancelar un temporizador o registrar un evento— eso es un hecho del dominio y su vehículo sigue siendo una acción delegate que sube al ancestro común. Usar la caja compartida como canal de notificación entre hermanos, escribiendo un contador o un booleano que el otro espera ver cambiar, es reinventar la comunicación por variable global con todos sus defectos: sin orden garantizado, sin registro en el log y sin nada que afirmar en un test.

Queda un corolario incómodo: si el estado compartido puede cambiar sin que la feature procese acción alguna, el estado que un reducer ve al empezar puede no ser el que vio al terminar la acción anterior. En la práctica esto rara vez muerde, porque las escrituras ocurren en reducers y los reducers de un mismo store no corren a la vez; pero deja de ser cierto en cuanto alguien escribe desde dentro de un efecto, en otro hilo. De ahí la disciplina que cierra esta lección: se escribe desde el reducer, con el valor que traiga la acción; el efecto envía una acción con el resultado y es el reducer quien la escribe.

En código, la disciplina es un patrón de dos tiempos que ya conoces del nivel diez y que aquí gana una razón más para respetarse:

case .recargarPerfilPulsado:
  return .run { [id = state.usuario.id] send in
    await send(.perfilLlego(Result { try await self.api.perfil(id) }))
  }

case let .perfilLlego(.success(perfil)):
  state.$usuario.withLock { $0.aplicar(perfil) }   // el reducer escribe
  return .none

case .perfilLlego(.failure):
  state.error = .noSePudoRecargar
  return .none

El efecto no toca la caja: transporta un valor y termina. La escritura ocurre en el único sitio donde está ordenada respecto a todas las demás acciones del store, aparece en el registro asociada a la acción que la causó y se afirma en el test con la aserción de receive. Capturar $usuario dentro del run y escribir allí ahorraría cuatro líneas y perdería las tres propiedades a la vez.

Conviene además señalar dónde se escribe cuando lo que cambia es una parte. Si una feature solo posee la caja de una propiedad —recibió $usuario.plan en lugar de $usuario— escribe sobre esa caja derivada y el efecto sobre el objeto completo es el esperado: state.$plan.withLock modifica el mismo Usuario que los demás observan, pero esa feature nunca tuvo acceso al resto de campos. Rebanar la caja al entregarla es, por tanto, la forma más barata de limitar el alcance de una escritura sin escribir ni una comprobación.

Afirmar la escritura

El TestStore trata la mutación compartida con la misma exigencia que cualquier otra, y la sintaxis de la aserción es idéntica a la de la escritura real.

await store.send(.planMejorado) {
  $0.$usuario.withLock {
    $0.plan = .profesional
    $0.creditos += 100
  }
}

Lo interesante es el segundo caso, el de la feature que no escribió. Un test de Ajustes puede afirmar el efecto de una escritura ajena inyectándola directamente sobre la caja, lo que permite probar la reacción a un cambio externo sin montar la feature que lo produce ni la jerarquía que las une:

let usuario = Shared(value: Usuario(nombre: "Ada", plan: .gratuito))
let store = TestStore(initialState: Ajustes.State(usuario: usuario)) {
  Ajustes()
}

usuario.withLock { $0.plan = .profesional }        // escribe otro, desde fuera
await store.send(.aparecio) {
  $0.seccionesVisibles = .todas                     // la reacción propia sí se afirma
}

Es el reflejo exacto del contrato delegate del nivel catorce, ahora en clave de datos: cada lado se prueba solo, contra la frontera y no contra el otro. Y la asimetría del ejemplo es instructiva —la escritura ajena se ejecuta sin aserción porque no la produjo esta feature, mientras que todo lo que sí produce el reducer bajo prueba sigue exigiendo su declaración—, porque es la traducción literal a testing de la regla que gobierna la lección: cada feature responde de lo que escribe, y solo de eso.

flowchart TD
R[Reducer de Perfil] -->|withLock| C[Caja compartida]
C -->|invalidacion por lectura| V1[Vista de Perfil]
C -->|invalidacion por lectura| V2[Vista de Ajustes]
C -->|invalidacion por lectura| V3[Vista de Cabecera]
C -.->|no envia accion| RA[Reducer de Ajustes]
D[Hecho del dominio] -->|accion delegate| RA
style C fill:#a6e3a1,color:#11111b
style RA fill:#f9e2af,color:#11111b