inMemory: lo compartido que no sobrevive al proceso

La conversación sobre persistencia tiende a plantearse como un interruptor: o el dato se guarda o no se guarda. Pero entre el estado local de una feature —que nace con ella, se copia por valor y muere cuando su pantalla se cierra— y el estado escrito en disco —que sobrevive al proceso, al reinicio y a veces al propio dispositivo— hay una región intermedia perfectamente real y sistemáticamente mal atendida: lo que varias partes de la app necesitan ver a la vez durante una ejecución, y que sería un error conservar más allá de ella. Un token descifrado, la sesión en curso, un carrito que aún no es un pedido. @Shared(.inMemory) nombra esa región, y al nombrarla obliga a decidir explícitamente algo que casi siempre se decide por descuido.

Tres modos de tener un valor

Conviene ordenar el espacio antes de recorrerlo, porque la elección equivocada casi nunca se manifiesta como un error de compilación sino como una arquitectura que se resiste a los cambios.

La tercera columna es la que decide, y la pregunta que la resuelve no es técnica sino de dominio: ¿este valor tiene sentido mañana? Un token de sesión descifrado no lo tiene, y guardarlo en un fichero es una vulnerabilidad, no una comodidad. Un borrador a medio escribir sí lo tiene, y perderlo al cerrar es un bug aunque nadie lo haya reportado. inMemory existe para que la primera respuesta tenga dónde vivir sin caer por inercia en la segunda.

Compartir por nombre

La declaración es la de siempre, con la clave cambiada.

@ObservableState
struct State: Equatable {
  @Shared(.inMemory("sesion")) var sesion: Sesion? = nil
}

No hay requisito de Codable porque no hay serialización: el valor vive en un almacén en memoria que el sistema de dependencias mantiene durante toda la ejecución. Al arrancar, la clave no tiene nada y se usa el valor por defecto de la declaración; a partir de ahí, cualquier feature que nombre la misma clave obtiene la misma referencia, con la misma semántica de lectura directa y mutación bajo withLock que ya conoces.

case let .sesionIniciada(sesion):
  state.$sesion.withLock { $0 = sesion }
  return .none

case .cerrarSesionTocado:
  state.$sesion.withLock { $0 = nil }
  return .none

La cadena vuelve a ser un espacio de nombres global y sin comprobación de tipos, y aquí el riesgo es mayor que en las claves persistidas porque no hay ningún fichero que inspeccionar cuando algo va mal. Dos declaraciones con la misma cadena y tipos distintos son un error que ningún compilador detecta y que se manifiesta en ejecución, lejos de su causa. La profilaxis es la misma de las lecciones anteriores y no admite excepciones.

extension SharedKey where Self == InMemoryKey<Sesion?>.Default {
  static var sesion: Self { Self[.inMemory("sesion"), default: nil] }
}

@Shared(.sesion) var sesion

Que el almacén pertenezca al contexto de dependencias tiene una consecuencia excelente y poco anunciada: cada test arranca con el almacén vacío, y cada previsualización también. No hay estado residual entre casos, no hay que acordarse de limpiar nada, y la clase entera de fallos donde un test pasa en solitario pero falla en la suite completa simplemente no se puede producir por esta vía.

Por nombre o por referencia: dos formas de compartir

inMemory no es la única manera de que dos features vean el mismo valor. Existe también la compartición explícita, en la que se construye una referencia compartida y se entrega a quien deba tenerla.

// Compartir por referencia: el vínculo es visible en el código que lo crea
let carrito = Shared(value: Carrito())
let tienda = Tienda.State(carrito: carrito)
let checkout = Checkout.State(carrito: carrito)

La diferencia entre ambas no es de potencia sino de visibilidad, y es exactamente la vieja tensión entre acoplamiento explícito e implícito. Con la referencia explícita, alguien —normalmente el padre— tuvo que decidir que estas dos features comparten esto, y esa decisión queda escrita en el punto de construcción: se puede leer, se puede buscar y se puede cambiar en un solo sitio. Con la clave con nombre, el vínculo no aparece en ninguna parte; existe porque dos ficheros, quizá escritos por dos personas distintas en dos meses distintos, coinciden en un símbolo.

La regla práctica se sigue de la última fila. Si el valor es genuinamente uno solo para toda la ejecución —hay una sesión, hay un usuario autenticado, hay un modo de conexión— la clave con nombre dice la verdad sobre el dominio y su ambientalidad es una descripción, no un atajo. Si en cambio puede haber dos —dos documentos abiertos, dos conversaciones, dos carritos— la clave con nombre miente, y la mentira se cobra el día que el producto pide justamente eso.

flowchart TD
L[Propiedad local del State] --> P1[Vive lo que su feature]
I[Shared inMemory] --> P2[Vive lo que el proceso]
D[Shared appStorage o fileStorage] --> P3[Vive mas que el proceso]
P2 --> C[Contexto de dependencias]
C --> T[Cada test arranca vacio]
C --> V[Cada preview arranca vacio]
style I fill:#f9e2af,color:#11111b
style C fill:#89b4fa,color:#11111b

El sustrato como variable de diseño

Lo más útil de inMemory quizá no sea su comportamiento sino su forma. Al compartir API con las claves persistidas, convierte el sustrato en un parámetro que se puede cambiar tarde y con seguridad. Un valor puede nacer en memoria mientras se decide si merece disco, ascender a fileStorage el día que el producto pide que sobreviva al cierre, o descender a memoria cuando una revisión de seguridad determina que no debía estar escrito. Ninguno de esos movimientos toca el reducer, ni las acciones, ni los tests de lógica: cambia una línea en la extensión donde vive la clave.

// Ayer, mientras se decidía
extension SharedKey where Self == InMemoryKey<[Borrador]>.Default {
  static var borradores: Self { Self[.inMemory("borradores"), default: []] }
}

// Hoy, sin tocar ninguna feature
extension SharedKey where Self == FileStorageKey<[Borrador]>.Default {
  static var borradores: Self {
    Self[.fileStorage(.documentsDirectory.appending(component: "borradores.json")), default: []]
  }
}