Deep linking: construir la pila entera desde una URL al arrancar

El enlace profundo es la prueba de fuego de cualquier arquitectura de navegación, y es donde el modelo imperativo enseña sin remedio su costura. Allí, abrir la aplicación en una pantalla honda significa reproducir la secuencia de empujes que habría hecho un usuario: empuja el catálogo, espera a que cargue, empuja el producto, espera, empuja la reseña. Es una coreografía dependiente del reloj, plagada de comprobaciones defensivas, imposible de probar sin simulador y con una tendencia notoria a aterrizar en sitios distintos según lo rápido que responda la red. Con la navegación modelada como datos, el enlace profundo pierde toda esa complejidad de golpe, porque deja de ser una secuencia que hay que ejecutar y pasa a ser un valor que hay que construir. La aplicación no viaja hasta el destino: nace allí.

La ruta como función pura

El primer paso no toca ni el store ni la vista: es una función que recibe una URL y devuelve una colección de estados. Al no depender de nada más, se prueba con una tabla de casos y se corrige sin abrir la aplicación.

extension Tienda.State {
  static func camino(desde url: URL) -> StackState<Tienda.Camino.State> {
    guard let partes = URLComponents(url: url, resolvingAgainstBaseURL: false) else {
      return StackState()
    }
    switch partes.path.split(separator: "/").map(String.init) {
    case ["producto", let pid]:
      return StackState([.producto(Producto.State(id: pid))])
    case ["producto", let pid, "resena", let rid]:
      return StackState([
        .producto(Producto.State(id: pid)),
        .resena(Resena.State(id: rid)),
      ])
    default:
      return StackState()
    }
  }
}

Fíjate en la degradación: una ruta desconocida devuelve una pila vacía, es decir, la raíz. No hay excepción, ni pantalla de error, ni estado a medio construir; el peor caso posible de un enlace corrupto es que el usuario abra la aplicación por su portada. Esa robustez no es mérito del código sino del tipo de retorno: cuando la respuesta obligatoria es una pila válida, no existe la posibilidad de devolver media navegación.

Arrancar con la pila ya construida

Con la traducción resuelta, el arranque consiste en pasarle al store un estado inicial que ya contiene el camino. La aplicación se dibuja una sola vez, directamente en su forma final.

@main
struct TiendaApp: App {
  let store: StoreOf<Tienda>

  init() {
    let camino = URL.enlaceDeLanzamiento.map(Tienda.State.camino(desde:)) ?? StackState()
    self.store = Store(initialState: Tienda.State(camino: camino)) {
      Tienda()
    }
  }

  var body: some Scene {
    WindowGroup {
      TiendaView(store: store)
        .onOpenURL { url in store.send(.enlaceRecibido(url)) }
    }
  }
}

No hay espera, ni encadenamiento, ni comprobación de que la pantalla anterior terminó de presentarse. El NavigationStack recibe un camino de dos elementos en su primer dibujo y monta las dos pantallas de una vez, cada una con su store derivado y su reducer corriendo. Y como cada destino se construyó con su State completo, ninguna necesita descubrir quién es a partir de un identificador suelto.

En caliente, y de vuelta desde el disco

Cuando el enlace llega con la aplicación funcionando, la operación es la misma con otro nombre: en vez de construir el estado inicial, se reemplaza el campo.

case let .enlaceRecibido(url):
  state.camino = Tienda.State.camino(desde: url)
  return .none

Una línea sustituye la navegación entera, venga el usuario de donde venga. Lo que había en la pila se descarta, y con ello se cancelan automáticamente todos los efectos en vuelo de las pantallas retiradas: la garantía de forEach cubre también las sustituciones masivas, no solo los retrocesos de uno en uno.

La restauración de sesión es literalmente el mismo mecanismo con otro origen. Si los estados de los destinos son codificables, StackState lo es, y guardar dónde estaba el usuario se reduce a serializar un valor al salir y deserializarlo al volver.

// Al pasar a segundo plano
try? Data(JSONEncoder().encode(store.camino)).write(to: .sesion)

// Al arrancar
let camino = (try? JSONDecoder().decode(
  StackState<Tienda.Camino.State>.self, from: Data(contentsOf: .sesion)
)) ?? StackState()

flowchart LR
U[URL entrante] --> F[Funcion pura de traduccion]
F --> P[StackState construido]
P --> I[Estado inicial del store]
P --> H[Sustitucion en caliente]
D[Sesion en disco] --> P
I --> V[La vista monta la pila entera]
H --> V
style F fill:#89b4fa,color:#11111b
style V fill:#a6e3a1,color:#11111b

Quedan dos matices que separan la demostración de la producción. El primero es la animación: al asignar varias pantallas de una vez con la aplicación en marcha, SwiftUI intentará animar la diferencia completa, lo que produce una transición atropellada; si el salto es largo, conviene aplicarlo sin animación y dejar visible solo el resultado. El segundo es la carga de datos: una pantalla que solo pide sus datos al aparecer los pedirá también al llegar por enlace profundo, así que si te importa que no parpadee, construye su State con lo que ya sabes en lugar de dejarla vacía a la espera.