SwiftUI Series 05 ｜ Uso correcto de NavigationStack y salto de página

Cuando use NavigationStack por primera vez, pensará que es la versión SwiftUI del contenedor de navegación:

• Haga clic
• empujar una página
• Eso es todo.

Pero en proyectos reales, la parte realmente problemática de la navegación es siempre:

• La página saltará
• Si el estado del salto y el estado del negocio son consistentes
• Si la ruta aún puede permanecer correcta al realizar enlaces profundos, regresar y volver a ingresar a la página.

En otras palabras, con lo que realmente tiene que lidiar NavigationStack no es solo con el cambio de interfaz, sino con el estado de navegación en sí.

1. Los problemas de navegación de muchos proyectos en el pasado provinieron esencialmente de “acciones de salto dispersas por todas partes”

En la era UIKit, una forma de escribir muy común es:

• Presione directamente en un botón
• Presentar directamente en una devolución de llamada
• Cuando un ViewModel vuelve a llamar, salta a través del delegado

Por supuesto que funcionará a corto plazo, pero el problema es que la lógica de navegación estará cada vez más dispersa. Difícil de responder:

• ¿Por qué estás en esta página?
• ¿A qué estado deberías volver después de regresar?
• Una vez completado un determinado negocio, saltará a dos niveles.

NavigationStack de SwiftUI ofrece una mejor oportunidad: Cambie la “ruta de navegación actual” de acción implícita a estado explícito.

2. Lo más importante de NavigationStack es el camino

Cuando descubrí por primera vez este contenido NavigationStack, simplemente me quedé mirando:

• NavigationLink
• navigationDestination

Por supuesto que necesitas saber esto, pero lo que realmente debes entender primero es:

La navegación se puede expresar como una ruta de estado en SwiftUI.

Esto ya no significa simplemente “saltar al hacer clic”, sino mantener:

• ¿Qué páginas hay en la ruta actual?
• Qué situación comercial corresponde a qué destino
• ¿Cómo debería cambiar el camino después de una determinada operación?

Una vez vista desde esta perspectiva, la navegación deja de ser solo un evento de la interfaz de usuario y comienza a convertirse en parte del flujo de estado.

3. Muchas navegaciones se estropean porque el estado del negocio y el estado de la ruta no están alineados.

Para dar un ejemplo muy común:

• El usuario selecciona un artículo.
• Debería aparecer la página de detalles del artículo.
• ¿Cómo salir de la página de detalles después de eliminar un artículo?

Si entiende la navegación como “haga clic para ingresar”, muchas preguntas posteriores comenzarán a resultar confusas:

• Cómo restaurar la ruta cuando llega un enlace profundo
• Cómo ajustar la ruta después de una falla de datos
• En qué estado debe permanecer la lista cuando se devuelva

Entonces, lo realmente difícil de la navegación es que no debería existir independientemente del estado del negocio.

Una idea más estable es:

• La ruta de navegación y el estado del negocio son mutuamente interpretables.
• El motivo por el que se encuentra actualmente en esta página se puede explicar claramente en el estado.

4. NavigationLink es muy conveniente, pero una vez que el proyecto es complejo, no puede confiar en él para expresar toda la navegación.

NavigationLink es especialmente adecuado para saltos directos, parciales y simples, como por ejemplo:

• Haga clic en la lista para obtener más detalles.
• Establecer la configuración de alimentación de páginas

Pero si el proyecto es complejo, si toda la navegación se basa en NavigationLink dispersos, pronto encontrará:

• Los caminos son difíciles de gestionar de manera uniforme.
• Los enlaces profundos son de difícil acceso.
• Ciertos saltos de proceso ya no se realizan simplemente mediante clics.
• La ruta de regreso está desconectada del estado comercial.

Es por eso que es más adecuado para asumir entradas locales y no para llevar la estrategia de navegación de toda la aplicación por sí sola.

5. Una idea más práctica: diseñar el “destino de la página” como un valor que la empresa pueda explicar

Una de las causas fundamentales de muchos accidentes de navegación en proyectos es:

• Los saltos simplemente se escriben como un conjunto de acciones de la interfaz de usuario.
• No se forma ningún modelo de destino razonable.

Un método más estable suele ser dejar que el camino indique “a qué destino quiere ir el negocio actual”.

Por ejemplo:

• Detalle del artículo (id: Cadena)
• perfil de usuario (id: cadena)
• configuración

De esta manera, la navegación se parece más a estados que a una colección inconexa de acciones. Sus beneficios son:

• Los caminos se pueden reconstruir.
• Los enlaces profundos son más naturales.
• Las pruebas y la depuración también son más fáciles de describir.

6. El mal olor más común en proyectos reales: las acciones de Vista, Modelo de Vista y enrutamiento están entrelazadas entre sí.

Gran parte del código de navegación de SwiftUI termina luciendo así:

• Escribir parte de NavigationLink en View
• ViewModel decidió en secreto saltar de nuevo.
• Una determinada devolución de llamada de servicio desencadena un cambio de estado de navegación.

Al final nadie puede decirlo claramente:

• ¿Quién es el verdadero propietario de la navegación?
• ¿Qué estado determina el camino actual?
• ¿Una determinada acción de devolución es un comportamiento de usuario o un comportamiento empresarial?

Una vez que la navegación entra en este estado, el costo de agregar un enlace profundo o agregar una ruta de recuperación aumentará significativamente.

7. Un juicio práctico: ¿La página actual es “porque hice clic” o “porque el estado determina que debería estar aquí”

Esto es algo que me pregunto a menudo.

Si aparece una página, sólo se puede interpretar como:

• Porque acabo de hacer clic en un botón.

Por lo general, eso significa que la navegación todavía está demasiado basada en la acción.

Una explicación más ideal debería ser:

• porque el estado de la ruta actual lo contiene
• porque el contexto empresarial actual dicta que debe mostrarse

Esta diferencia es importante. La primera se parece más a una acción temporal, la segunda se parece más a un estado de navegación mantenible.

8. Conclusión: Lo que NavigationStack realmente permite gestionar no son sólo los saltos, sino también el estado de la ruta.

Para decirlo en forma más breve, diría:

NavigationStack Lo realmente importante es que permite cerrar la navegación de forma más natural desde “acciones de clic dispersas” hasta “estados de ruta manejables”.

Por lo tanto, la forma correcta de abrir el salto de página no es simplemente escribir NavigationLink, sino permitir que el estado de navegación y el estado comercial se expliquen entre sí. Sólo así la navegación no será cada vez más confusa a medida que el proyecto se vuelva más complejo.