El enrutado, que ya no es enrutado

Qué modo usar

La recomendación es clara y contraintuitiva para quien viene de la web: por fragmento, o sin enrutador. Las rutas limpias existen para que las URLs se vean bien, y aquí no hay quien las vea.

El historial

Y la pregunta que sigue: ¿el botón de atrás existe en tu aplicación?

• En una web, sí, y el usuario lo espera: el navegador lo pone.
• En una aplicación de escritorio no hay botón de atrás del sistema, salvo que tú lo pongas.

Y eso cambia el significado del historial: en la web es una lista de sitios visitados; aquí es, si acaso, un mecanismo de navegación interna que tú decides ofrecer.

Dos posturas válidas:

• Sin historial: la aplicación tiene una estructura de pantallas y se navega por su interfaz. Es lo que hacen casi todas las aplicaciones de escritorio.
• Con historial explícito: si tu aplicación es de las que se explora —un navegador de documentación, un visor— y tiene sentido volver atrás, con atajos y botones propios.

Lo que no vale es depender del historial del navegador sin ofrecer forma de usarlo: el usuario no tiene botón de atrás, así que si tu navegación mete entradas en el historial y nada las consume, están de adorno.

¿Necesitas rutas?

Merece preguntárselo, porque la respuesta a veces es no:

Rutas y enlaces profundos

Cuando sí hay rutas, conviene que el mapeo entre enlace externo y ruta interna sea explícito:

// el core traduce el enlace a una acción, y el frontend recibe la acción — no la rutafn accion_de(enlace: &Url) -> Option<Accion> {    match (enlace.host_str(), enlace.path()) {        (Some("proyecto"), p) => p.trim_start_matches('/').parse().ok().map(Accion::AbrirProyecto),        (Some("ajustes"), _) => Some(Accion::AbrirAjustes),        _ => None,    }}

Y no traducir la ruta del enlace directamente a una ruta del frontend, por dos razones: sería el mapeo genérico que el nivel 51.2 desaconseja, y ataría tu esquema de enlaces públicos a la estructura interna de tu interfaz — que va a cambiar.