El mapa de destinos: diseñar la navegación de una app entera

Un mapa de destinos es a la navegación lo que un esquema de base de datos es a la persistencia: el documento breve que decide, antes de que exista una sola pantalla, qué trayectos serán posibles y cuáles no. Casi nadie lo escribe, y por eso casi todas las apps acaban con una navegación que nadie diseñó sino que se sedimentó, pantalla a pantalla, según lo que hiciera falta el martes. El coste no aparece de golpe: aparece el día en que hay que abrir la app desde una notificación, o mostrar la misma pantalla desde dos sitios distintos, o explicarle a alguien nuevo por qué esa alerta vive donde vive. Esta lección hace el ejercicio completo sobre una app plausible —tres pestañas, trayectos que se repiten, modales, una sesión que puede expirar— y demuestra que el mapa cabe en una tabla, que la tabla se traduce a tipos casi mecánicamente y que, una vez escrito, responde solo a las preguntas que antes costaban una tarde de discusión.

El inventario: de pantallas a destinos

Toma una app de recetas con tres pestañas. Explorar permite buscar, abrir una receta, ver el perfil de su autor y desde ahí abrir otra receta suya, indefinidamente. Despensa lista ingredientes y permite editarlos en un formulario y borrarlos con confirmación. Perfil muestra ajustes y puede cerrar sesión. Por encima de todo hay una sesión que, si expira, debe llevar al usuario a la pantalla de acceso sin importar dónde estuviera.

El inventario se escribe clasificando cada transición en tres categorías, y esa clasificación ya decide la forma del tipo. Continúa el trayecto, y entonces es un elemento de pila. Lo interrumpe con un conjunto cerrado de salidas, y entonces es un hueco de destino en la pantalla que interrumpe. O cambia el contexto entero, y entonces pertenece a la raíz.

La tabla ya contiene todas las decisiones difíciles. Que Receta lleve a Autor y Autor lleve a Receta obliga a la pila, porque un enum de destino no puede contenerse a sí mismo. Que la hoja de compartir viva en Receta y no en la pila impide que el gesto de volver atrás la trate como una pantalla más. Y que la pantalla de acceso viva en la raíz, no dentro de Perfil, es lo que hace que la sesión expirada funcione igual desde cualquier pestaña.

El esqueleto de tipos de una app entera

La traducción de la tabla a tipos es casi mecánica: una pila por pestaña, un enum de camino por pila, un hueco de destino en cada pantalla que interrumpa y un hueco más en la raíz para lo global.

@Reducer
struct AppCocina {
  @Reducer
  enum Modal {                       // lo global: cambia el contexto entero
    case acceso(Acceso)
    case bienvenida(Bienvenida)
  }

  @Reducer
  enum CaminoExplorar {              // el trayecto recursivo
    case receta(Receta)
    case autor(Autor)
  }

  @ObservableState
  struct State: Equatable {
    var pestana: Pestana = .explorar
    var explorar = Explorar.State()
    var caminoExplorar = StackState<CaminoExplorar.State>()
    var despensa = Despensa.State()
    var perfil = Perfil.State()
    var caminoPerfil = StackState<CaminoPerfil.State>()
    @Presents var modal: Modal.State?
  }

  enum Pestana: Equatable { case explorar, despensa, perfil }

  enum Action {
    case pestanaCambiada(Pestana)
    case explorar(Explorar.Action)
    case caminoExplorar(StackActionOf<CaminoExplorar>)
    case despensa(Despensa.Action)
    case perfil(Perfil.Action)
    case caminoPerfil(StackActionOf<CaminoPerfil>)
    case modal(PresentationAction<Modal.Action>)
    case sesionExpiro
  }
}

Dos detalles del esqueleto valen más que todo el resto. El primero es que hay una pila por pestaña y no una sola compartida: cada pestaña conserva su propio trayecto cuando el usuario la abandona y vuelve, que es lo que cualquiera espera de una app de pestañas y lo que una pila global rompería. El segundo es que el modal global vive en la raíz, no dentro de ninguna pestaña, y por eso la sesión expirada se resuelve en una línea desde cualquier punto de la app.

Las costuras: quién empuja, quién descarta y quién no se entera

Con los tipos puestos, falta decidir quién toma cada decisión de navegación. La regla es la del bloque de composición, aplicada sin excepciones: una pantalla nunca se navega a sí misma hacia fuera. Informa de un hecho con un delegate y el dueño de la pila decide qué hacer con él.

var body: some ReducerOf<Self> {
  Scope(state: \.explorar, action: \.explorar) { Explorar() }
  Scope(state: \.despensa, action: \.despensa) { Despensa() }
  Scope(state: \.perfil, action: \.perfil) { Perfil() }

  Reduce { state, action in
    switch action {
    case let .explorar(.delegate(.recetaAbierta(id))):
      state.caminoExplorar.append(.receta(Receta.State(id: id)))
      return .none

    case let .caminoExplorar(.element(id: _, action: .receta(.delegate(.autorAbierto(id))))):
      state.caminoExplorar.append(.autor(Autor.State(id: id)))
      return .none

    case let .caminoExplorar(.element(id: _, action: .autor(.delegate(.recetaAbierta(id))))):
      state.caminoExplorar.append(.receta(Receta.State(id: id)))
      return .none

    case .sesionExpiro:
      state.caminoExplorar.removeAll()
      state.caminoPerfil.removeAll()
      state.modal = .acceso(Acceso.State())
      return .none

    default:
      return .none
    }
  }
  .ifLet(\.$modal, action: \.modal)
  .forEach(\.caminoExplorar, action: \.caminoExplorar)
  .forEach(\.caminoPerfil, action: \.caminoPerfil)
}

Fíjate en el caso de la sesión expirada: tres asignaciones y la app entera queda en un estado coherente, con los dos trayectos vaciados y el acceso presentado. En un modelo imperativo eso mismo exigiría recorrer la jerarquía de vistas descartando presentaciones en el orden correcto y esperando animaciones, con resultado distinto según dónde estuviera el usuario. Aquí no hay orden ni espera: hay un valor nuevo.

flowchart TD
R[Raiz] --> M[Modal global: acceso o bienvenida]
R --> T1[Pestana Explorar]
R --> T2[Pestana Despensa]
R --> T3[Pestana Perfil]
T1 --> P1[Pila de Explorar]
P1 --> RC[Receta]
P1 --> AU[Autor]
RC -->|delegate| P1
AU -->|delegate| P1
RC --> D1[Hueco: compartir o alerta]
T2 --> D2[Hueco: formulario o alerta]
T3 --> P3[Pila de Perfil]
style M fill:#f9e2af,color:#11111b
style P1 fill:#a6e3a1,color:#11111b
style R fill:#89b4fa,color:#11111b