La estrategia incremental: de la hoja hacia la raíz

La pregunta que abre este nivel no es cómo se escribe una feature en TCA, cosa que llevas veintiocho niveles sabiendo, sino qué se hace con las cuarenta pantallas que ya existen y que son las que pagan las nóminas. La respuesta que aparece en la primera reunión es siempre reescribir, y es casi siempre la equivocada, por razones que tienen menos que ver con la arquitectura que con la economía de los proyectos largos. La respuesta buena es más modesta y bastante más difícil de defender ante un calendario: instalar la arquitectura nueva en un rincón donde no moleste, comprobar que sobrevive al contacto con el código real y dejar que crezca hacia el centro. Esta lección trata de cómo se elige ese rincón, qué forma tiene el injerto y por qué la dirección importa más que la velocidad.

El argumento contra la reescritura

Conviene tener el argumento afilado, porque lo vas a tener que sostener varias veces. El primero es económico: durante una reescritura conviven dos productos, el que se mantiene y el que se construye, y el segundo no entrega nada hasta que alcanza la paridad con el primero. La curva de valor es plana durante meses y todo el riesgo se concentra en el único día en que por fin se puede comprobar si aquello funciona. El segundo argumento es epistemológico y es el que más se subestima: una parte grande del conocimiento del dominio no está documentada, está en el código, y sobre todo está en las líneas que parecen absurdas. Cada condición rara que nadie recuerda haber escrito suele ser un incidente que alguien vivió a las tres de la mañana. Reescribir es tirar ese archivo y volver a comprarlo al mismo precio.

La alternativa se llama estrangulamiento por analogía con la higuera que crece alrededor de un árbol hasta sustituirlo: se instala la estructura nueva junto a la vieja, se traslada funcionalidad pieza a pieza y en todo momento el sistema entero es publicable. Lo que hace a TCA inusualmente apto para esta forma de crecer es una propiedad concreta y fácil de pasar por alto: el Store es un objeto corriente que se construye donde quieras. No exige un contenedor de aplicación, ni un árbol raíz, ni un registro global inicializado al arrancar. Una pantalla puede tener su propio Store mientras las otras treinta y nueve no saben que existe, y eso no es un apaño tolerado sino el modo normal de operar de la librería.

Qué es exactamente una hoja

La intuición dice que una hoja es una pantalla pequeña, pero el tamaño no tiene nada que ver. La definición operativa tiene dos condiciones, y la segunda es la que se olvida. Primera: grado de salida cero en el grafo de navegación, es decir, la pantalla no presenta ni empuja ninguna otra. Segunda: no escribe en estado mutable que otras pantallas lean, lo que descarta la pantalla que actualiza la sesión, la que invalida una caché compartida o la que toca un singleton de configuración que media app consulta.

Cumplen las dos condiciones muchas más pantallas de las que parece: un detalle de solo lectura, una edición de un campo aislado, la pantalla de una preferencia, un paso de un asistente, una ficha de ayuda. Empezar por ahí no es cobardía metodológica; es que en una hoja el injerto se prueba entero —modelado, efectos, dependencias, tests— con un radio de daño de una pantalla.

@Reducer
struct EditarNota {
  @ObservableState
  struct State: Equatable {
    var texto: String
    var guardando = false
    var error: String?
    var guardado: Nota?
  }
  enum Action {
    case textoCambiado(String)
    case guardarPulsado
    case guardadoRecibido(Result<Nota, Error>)
    case delegate(Delegate)
    enum Delegate { case seGuardo(Nota) }
  }
  @Dependency(\.notasCliente) var notas
  var body: some ReducerOf<Self> {
    Reduce { estado, accion in
      switch accion {
      case let .textoCambiado(t):
        estado.texto = t
        return .none
      case .guardarPulsado:
        estado.guardando = true
        return .run { [texto = estado.texto] envio in
          await envio(.guardadoRecibido(Result { try await notas.guardar(texto) }))
        }
      case let .guardadoRecibido(.success(nota)):
        estado.guardando = false
        estado.guardado = nota
        return .send(.delegate(.seGuardo(nota)))
      case let .guardadoRecibido(.failure(fallo)):
        estado.guardando = false
        estado.error = fallo.localizedDescription
        return .none
      case .delegate:
        return .none
      }
    }
  }
}

La forma de la frontera

El injerto necesita un punto de anclaje, y el punto de anclaje es siempre el mismo: una vista envoltorio que construye el Store, dibuja la feature y traduce la acción delegate en el vocabulario que el mundo viejo entiende, que casi siempre es un cierre. Hacia dentro entran valores planos; hacia fuera salen hechos consumados. Nada más cruza.

struct EditarNotaPuente: View {
  @State var store: StoreOf<EditarNota>
  let alGuardar: (Nota) -> Void

  init(texto: String, alGuardar: @escaping (Nota) -> Void) {
    self.store = Store(initialState: EditarNota.State(texto: texto)) { EditarNota() }
    self.alGuardar = alGuardar
  }

  var body: some View {
    EditarNotaView(store: store)
      .onChange(of: store.guardado) { _, nueva in
        if let nueva { alGuardar(nueva) }
      }
  }
}

// Desde el mundo viejo, sin enterarse de nada
let vc = UIHostingController(
  rootView: EditarNotaPuente(texto: nota.texto) { [weak self] guardada in
    self?.viewModel.actualizar(guardada)
  }
)

El puente observa un campo del estado y no la acción, porque el flujo de acciones de un Store no es un canal público al que se pueda suscribir nadie desde fuera; el hecho consumado se publica dejándolo escrito en el estado, que sí es observable. Fíjate en la simetría: ese cierre es la versión degradada de la acción delegate del Nivel 14. El padre viejo recibe por cierre exactamente lo mismo que un padre en TCA recibiría por acción, y por eso el día que el padre se migre bastará con sustituir el cierre por el enrutado de la acción y borrar el puente. La frontera está diseñada desde el principio para desaparecer.

Hacia la raíz: la coalescencia de islas

Cuando dos hojas hermanas ya viven en TCA, el padre pasa de ser un trabajo grande a ser uno pequeño: su estado es la suma de dos estados ya modelados más un enum de destinos, y su reducer es un Scope por hijo más el enrutado de sus acciones delegate. Ese es el efecto que hace que la migración se acelere en vez de agotarse, y es la razón profunda por la que se sube en lugar de bajar. Si empiezas por la raíz tienes que modelar todo el árbol de destinos antes de poder publicar la primera línea; si empiezas por las hojas, cada paso es un incremento aislado y el trabajo del padre lo pagan los hijos ya hechos.

flowchart BT
H1[Hoja migrada uno] --> P[Padre aun en el mundo viejo]
H2[Hoja migrada dos] --> P
P --> R[Raiz de la app]
H1 -.puente de cierre.-> P
H2 -.puente de cierre.-> P
P ==absorcion posterior==> P2[Padre migrado con Scope y destinos]
style H1 fill:#a6e3a1,color:#11111b
style H2 fill:#a6e3a1,color:#11111b
style P2 fill:#89b4fa,color:#11111b