Persistir sin ensuciar el reducer: preferencias con appStorage

Hay un momento en toda app en el que alguien pregunta dónde se guarda el tema oscuro. La respuesta tradicional en TCA era un pequeño teatro de tres actos: una dependencia que sabe hablar con UserDefaults, una acción de arranque que la invoca para poblar el estado, y un efecto colgado de cada mutación que devuelve el valor al disco. Funciona, pero paga un precio que no siempre se contabiliza: la lógica de la feature queda salpicada de instrucciones sobre almacenamiento, y aparece una ventana temporal —entre que el estado cambia y el efecto termina— en la que la memoria y el disco discrepan. @Shared(.appStorage) propone otra cosa: que la persistencia no sea algo que el reducer hace, sino algo que el estado es. Esta lección desmonta esa afirmación hasta el nivel de la firma de tipos.

El reducer no tiene por qué saber que hay un disco

Considera la versión clásica. Se inyecta un cliente, se añade una acción de aparición para leer, y cada mutación arrastra su efecto de escritura.

// El ritual de tres actos, antes de @Shared
@Reducer
struct Ajustes {
  @Dependency(\.userDefaults) var userDefaults

  @ObservableState
  struct State: Equatable { var tema: Tema = .sistema }

  enum Action { case aparecio, temaElegido(Tema) }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .aparecio:
        state.tema = self.userDefaults.tema()      // acto uno: cargar
        return .none
      case let .temaElegido(tema):
        state.tema = tema                           // acto dos: mutar
        return .run { _ in                          // acto tres: guardar
          await self.userDefaults.setTema(tema)
        }
      }
    }
  }
}

Tres piezas para una preferencia, y ninguna de ellas habla del dominio: hablan de infraestructura. Peor aún, la corrección depende de una convención no verificable —recordar el efecto en cada rama que toque tema— que ningún compilador puede imponer. El día que una cuarta acción modifique el tema y nadie añada su return .run, la app funcionará perfectamente hasta el siguiente arranque, que es el peor momento posible para descubrir un bug. Y mientras el efecto está en vuelo existe un intervalo en el que la memoria dice una cosa y el disco otra: una ventana de incoherencia que en la práctica se cierra sola, salvo cuando el sistema mata el proceso justo ahí.

La declaración: el valor por defecto es el fondo, no el dato

La alternativa cabe en una línea, y esa línea vive en el State.

@ObservableState
struct State: Equatable {
  @Shared(.appStorage("tema")) var tema: Tema = .sistema
  @Shared(.appStorage("vioLaBienvenida")) var vioLaBienvenida = false
}

El valor asignado en la declaración no es el valor inicial en el sentido habitual: es el valor de reposo cuando la clave no existe todavía en UserDefaults. Si hay algo guardado, gana lo guardado; si no lo hay, se usa el defecto y no se escribe nada, de modo que la clave permanece ausente hasta la primera mutación real del usuario. Esa asimetría importa: permite distinguir a posteriori entre alguien que nunca eligió tema y alguien que eligió explícitamente el del sistema, cosa imposible si la app escribe el defecto en el primer arranque.

La clave de texto libre es cómoda y peligrosa a partes iguales: es un espacio de nombres global, sin comprobación de tipos, compartido con cualquier otra parte del binario. La disciplina consiste en no escribirla nunca dos veces, y para eso se extiende el propio tipo de clave.

extension SharedKey where Self == AppStorageKey<Tema>.Default {
  static var tema: Self { Self[.appStorage("tema"), default: .sistema] }
}

// En cualquier feature, sin repetir la cadena ni el defecto:
@Shared(.tema) var tema

Ahora la clave es un símbolo: el compilador la comprueba, el autocompletado la ofrece y el defecto vive en un solo sitio. Cualquier feature que declare @Shared(.tema) no obtiene una copia sino la misma referencia compartida, de forma que un cambio en la pantalla de ajustes es visible de inmediato en la de perfil sin ninguna acción que lo comunique.

Qué cabe en appStorage y qué no

El sustrato es UserDefaults, y UserDefaults es una lista de propiedades, no un almacén de objetos arbitrarios. El conjunto admitido es corto y deliberado.

La última fila es una regla de higiene, no una limitación del framework. UserDefaults se materializa completo en memoria durante el arranque del proceso: meter ahí un historial de mil elementos serializado como Data no falla, simplemente encarece cada lanzamiento de la app para siempre. La frontera correcta es semántica: appStorage guarda decisiones del usuario sobre cómo quiere que la app se comporte, y esas decisiones son pocas, pequeñas y escalares.

Mutar exige un gesto: withLock

Leer es transparente —state.tema es el valor y punto—, pero escribir no se hace por asignación directa sino a través de la proyección.

case let .temaElegido(tema):
  state.$tema.withLock { $0 = tema }
  return .none

case .bienvenidaCompletada:
  state.$vioLaBienvenida.withLock { $0 = true }
  return .none

La incomodidad es intencional. Un valor compartido no es propiedad exclusiva del State que lo declara: es una referencia visible desde varias features y potencialmente desde varios hilos, así que la mutación tiene que ser una sección crítica y no una escritura suelta. withLock marca esa sección, hace atómica cualquier lectura y escritura combinada dentro de ella, y de paso deja en el código una señal tipográfica inconfundible de que ahí se está tocando algo que no es local. El resto del reducer sigue leyendo la propiedad sin ceremonia, que es exactamente donde se quiere la asimetría: lectura barata y ubicua, escritura rara y señalizada.

flowchart LR
A[Accion del usuario] --> R[Reducer muta con withLock]
R --> S[Referencia compartida]
S --> V[Vista redibuja]
S --> D[UserDefaults escribe]
E[Widget o extension cambia la clave] --> D
D --> S
style S fill:#89b4fa,color:#11111b
style D fill:#a6e3a1,color:#11111b