El problema que resuelve: bindings de presentación y estados imposibles

Un programador con experiencia en SwiftUI reconoce la lista de memoria: la hoja que se abre mostrando el dato anterior, la que no se abre porque otra se estaba cerrando, la alerta que reaparece una vez más de las que debía, el enlace de navegación que se activa solo al renderizarse una fila fuera de pantalla, el aviso de que se está modificando el estado durante una actualización de vista. La reacción habitual es tratarlos como rarezas del framework y aprender un repertorio de precauciones. Esta lección sostiene lo contrario: que no son rarezas sino consecuencias necesarias, que todas nacen de la misma raíz —modelar un hecho con varias variables que el compilador considera independientes— y que por eso ninguna precaución las cura del todo. Lo que las cura es cambiar el modelo, y el modelo correcto ya lo tienes: un solo hueco que o está vacío o contiene exactamente un destino.

Un hecho, varias variables: la aritmética del desastre

Empieza por lo más inocente que se pueda escribir: una pantalla que presenta un detalle y un formulario, cada uno con su bandera y su dato.

struct InventarioView: View {
  @State private var mostrandoDetalle = false
  @State private var itemSeleccionado: Item?
  @State private var mostrandoFormulario = false
  @State private var borrador: Item?
  @State private var mostrandoAlerta = false
}

Cinco variables booleanas u opcionales producen un espacio de treinta y dos combinaciones si contamos solo si cada una está puesta o no. De esas treinta y dos, exactamente cuatro tienen sentido en el dominio: nada presentado, detalle con item, formulario con borrador y alerta. Las otras veintiocho son estados imposibles que el tipo permite igualmente: bandera de detalle en verdadero con item nulo, item presente con bandera en falso, detalle y formulario a la vez, alerta encima de un formulario que ya se cerró. Ninguna de esas veintiocho es un error que alguien vaya a cometer conscientemente; todas son estados por los que el programa pasa durante una fracción de segundo mientras dos escrituras compiten, y basta esa fracción para que la vista se reconstruya y observe una contradicción.

La fórmula general es incómoda: con n presentaciones modeladas por separado hay dos elevado a n combinaciones y solo n más una son legítimas, así que la proporción de estados imposibles crece exponencialmente mientras el número de pantallas crece de una en una. Ninguna cantidad de cuidado gana esa carrera.

El catálogo: cada bug con su estado imposible detrás

La cuarta fila merece atención porque parece de otra familia y es de la misma. En una lista larga, SwiftUI construye filas que aún no están visibles; si la condición de presentación vive en la fila, construirla equivale a evaluarla, y una fila que nadie ha tocado puede activar su destino. El estado imposible aquí es más sutil: estar presentado dejó de ser una propiedad del modelo para ser una propiedad de la existencia de una vista, de modo que la navegación pasó a depender de un detalle de rendimiento del renderizador.

El hueco único: prohibir en vez de vigilar

La corrección no consiste en ordenar mejor las escrituras sino en hacer que las combinaciones inválidas no sean expresables. Un enum de destino en un único campo opcional reduce el espacio de treinta y dos a cuatro: nulo o exactamente uno de los tres casos, cada uno con el dato que necesita adherido a él.

@Reducer
struct Inventario {
  @Reducer
  enum Destino {
    case detalle(DetalleItem)
    case formulario(FormularioItem)
    case alerta(AlertState<Action.Alerta>)
  }

  @ObservableState
  struct State: Equatable {
    var items: IdentifiedArrayOf<Item> = []
    @Presents var destino: Destino.State?
  }

  enum Action {
    case filaTocada(Item.ID)
    case borrarTocado(Item.ID)
    case destino(PresentationAction<Destino.Action>)
    enum Alerta: Equatable { case confirmarBorrado(Item.ID) }
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .filaTocada(id):
        guard let item = state.items[id: id] else { return .none }
        state.destino = .detalle(DetalleItem.State(item: item))
        return .none

      case let .borrarTocado(id):
        state.destino = .alerta(.confirmarBorrado(de: id))
        return .none

      case let .destino(.presented(.alerta(.confirmarBorrado(id)))):
        state.items.remove(id: id)
        return .none

      case .destino:
        return .none
      }
    }
    .ifLet(\.$destino, action: \.destino)
  }
}

Tres propiedades caen juntas y ninguna depende de que nadie se equivoque. La primera: no existe presentado sin dato, porque el dato viaja dentro del caso del enum y no hay forma de construir el caso sin él. La segunda: no existen dos presentaciones simultáneas, porque un valor de enum solo puede estar en un caso, así que presentar la alerta mientras hay un detalle no abre dos puertas, sustituye una por otra de manera determinista. La tercera: el descarte por gesto llega al reducer como .destino(.dismiss) y pone el hueco a nulo antes de que tu código lo vea, de modo que el modelo nunca puede quedarse creyendo que sigue presentado.

flowchart TD
A[Cinco banderas independientes] --> B[Treinta y dos combinaciones]
B --> C[Cuatro validas]
B --> D[Veintiocho imposibles]
D --> E[Bugs intermitentes que dependen del orden de escritura]
F[Un hueco con enum de destino] --> G[Cuatro combinaciones]
G --> H[Todas validas por construccion]
style D fill:#f38ba8,color:#11111b
style H fill:#a6e3a1,color:#11111b