Lo que desbloquea: enlaces profundos, sesión restaurada y flujos testeados

Hay una prueba sencilla para saber si una abstracción merece su coste: comprobar si las tareas que antes eran caras se vuelven baratas, o si solo cambian de sitio. La navegación como dato pasa esa prueba de forma poco habitual, porque no abarata una tarea sino tres a la vez, y no por casualidad. Abrir la app en una pantalla profunda, devolver al usuario donde lo dejó ayer y verificar en un test que un flujo entero se comporta como debe parecen tres problemas distintos: uno de integración con el sistema, otro de persistencia y otro de calidad. En el modelo imperativo lo son, y cada uno se resuelve con su propia coreografía frágil. En el modelo de valores los tres colapsan en la misma operación —fabricar, guardar o comparar un valor— y esa convergencia no es un beneficio adicional de la arquitectura: es la señal de que la abstracción capturó algo real.

Un enlace profundo es un constructor, no un guion

En el modelo imperativo abrir la app en una pantalla profunda obliga a reproducir la historia: presentar la primera pantalla, esperar a que termine su animación, presentar la segunda, esperar otra vez. El resultado depende del tiempo, de si alguna pantalla intermedia decide mostrar una alerta y de que ninguna transición se solape con otra. Con la navegación como dato no hay historia que reproducir, porque el destino no es el residuo de un recorrido: es un valor que se puede escribir directamente.

extension AppRaiz.State {
  init(enlace url: URL) {
    self.init()
    guard url.scheme == "miapp" else { return }
    switch url.pathComponents.dropFirst() {
    case let partes where partes.first == "perfil":
      guard let id = partes.dropFirst().first.flatMap(UUID.init(uuidString:))
      else { return }
      self.camino.append(.perfil(Perfil.State(id: id)))
      if partes.contains("ajustes") {
        self.camino.append(.ajustes(Ajustes.State()))
      }
    default:
      return
    }
  }
}

// En el punto de entrada
WindowGroup {
  AppRaizView(store: Store(initialState: AppRaiz.State(enlace: url)) { AppRaiz() })
}

La aplicación arranca ya en el sitio correcto porque nunca estuvo en otro. No hubo dos pantallas antes que esta, no hubo animaciones encadenadas y no hubo ventana temporal en la que el estado fuese inconsistente. Y como el constructor es una función pura de URL a estado, se prueba sola: doce enlaces, doce comparaciones, sin arrancar la interfaz.

Restaurar la sesión: guarda la ruta, no el mundo

La tentación inmediata es hacer Codable el estado entero y volcarlo al disco al salir. Funciona el primer día y envejece mal, porque el estado incluye cosas que no deberían sobrevivir a un cierre: resultados de red ya caducados, banderas de carga, borradores a medias y campos que cambiarán de forma en la próxima versión. Lo que conviene persistir es una descripción mínima del trayecto, un valor pequeño y estable del que se pueda reconstruir el estado real.

// Descripción mínima del trayecto: identidad, no contenido
enum Paso: Codable, Equatable {
  case perfil(UUID)
  case publicacion(UUID)
  case ajustes
}

extension AppRaiz.State {
  var ruta: [Paso] {
    camino.compactMap { destino in
      switch destino {
      case let .perfil(estado): .perfil(estado.id)
      case let .publicacion(estado): .publicacion(estado.id)
      case .ajustes: .ajustes
      }
    }
  }

  init(ruta: [Paso]) {
    self.init()
    for paso in ruta {
      switch paso {
      case let .perfil(id): camino.append(.perfil(Perfil.State(id: id)))
      case let .publicacion(id): camino.append(.publicacion(Publicacion.State(id: id)))
      case .ajustes: camino.append(.ajustes(Ajustes.State()))
      }
    }
  }
}

La asimetría es deliberada: al guardar se descarta todo lo reconstruible y se conserva solo la identidad de cada escalón; al restaurar, cada pantalla vuelve a nacer en su estado inicial y vuelve a pedir sus datos como si el usuario acabase de llegar. El resultado es que la sesión restaurada nunca muestra información obsoleta y que un cambio en el estado interno de una feature no invalida lo que había en disco. La ruta es un contrato pequeño y por eso se puede versionar.

Testear un flujo entero sin tocar una vista

La tercera capacidad es la que convierte este nivel en algo más que ergonomía. Un flujo de navegación es una secuencia de estados, y afirmar sobre él es comparar valores, así que el TestStore sirve exactamente igual para probar un formulario que para probar cuatro pantallas encadenadas.

@Test
func altaDeItemDesdeElFormulario() async {
  let store = await TestStore(initialState: Inventario.State()) {
    Inventario()
  } withDependencies: {
    $0.uuid = .incrementing
  }

  await store.send(.anadirTocado) {
    $0.destino = .anadir(FormularioItem.State(item: Item(id: UUID(0))))
  }

  await store.send(.destino(.presented(.anadir(.set(\.item.nombre, "Tornillo"))))) {
    $0.destino?.anadir?.item.nombre = "Tornillo"
  }

  await store.send(.destino(.presented(.anadir(.guardarTocado))))

  await store.receive(\.destino.anadir.delegate.guardado) {
    $0.items.append(Item(id: UUID(0), nombre: "Tornillo"))
    $0.destino = nil
  }
}

Lee lo que afirma la última aserción: que tras guardar, el item aparece en la lista y el destino vuelve a ser nulo, es decir, que la hoja se cerró. Comprobar que una pantalla se cerró se ha convertido en comparar un opcional con nulo. No hay expectativas asíncronas, ni esperas por animación, ni identificadores de accesibilidad, ni un simulador arrancado: hay un valor antes, una acción y un valor después, que es la única forma de aserción que no se vuelve intermitente con el tiempo.

flowchart LR
U[URL de enlace profundo] --> C[Constructor de State]
D[Ruta guardada en disco] --> C
T[Acciones de un test] --> C
C --> S[Valor de navegacion]
S --> V[Vista]
S --> A[Asercion de igualdad]
S --> W[Codificacion a disco]
style S fill:#89b4fa,color:#11111b
style A fill:#a6e3a1,color:#11111b