Rutas con tipos seguros: el adiós a las cadenas

Hay una clase de error que ninguna revisión de código detecta con fiabilidad y que sin embargo se reproduce en todos los proyectos que usan rutas textuales: alguien cambia el nombre de un argumento en el sitio donde se declara y olvida cambiarlo en uno de los siete sitios donde se construye. El proyecto compila sin una sola advertencia, las pruebas unitarias pasan, y el fallo aparece en un dispositivo real como una pantalla vacía o una excepción de argumento ausente. La causa no es la falta de cuidado: es que se eligió representar una estructura tipada —un destino con sus parámetros— mediante una cadena de texto, es decir, mediante el tipo que por definición no lleva información sobre su contenido. Las rutas con tipos seguros no son una comodidad sintáctica ni azúcar sobre lo mismo de antes. Son el reconocimiento de que un destino siempre fue un valor con estructura, y de que escribirlo como texto era serializar demasiado pronto y perder por el camino todo lo que el compilador podía haber verificado gratis.

Lo que la cadena no podía saber

La ruta textual falla de cuatro maneras distintas, y conviene separarlas porque tienen remedios distintos y solo una desaparece con disciplina.

La primera es el nombre. Una ruta se declara en un sitio con un patrón y se construye en otro por concatenación; nada obliga a que coincidan. Renombrar un argumento es una operación que las herramientas de refactorización no pueden ayudarte a completar, porque para ellas no hay ninguna relación entre dos cadenas parecidas.

La segunda es el tipo. Todo argumento viaja como texto y hay que declarar aparte cómo interpretarlo. Si el patrón dice que un campo es entero y el sitio que construye la ruta mete un identificador alfanumérico, no hay error hasta que alguien pulsa.

La tercera es la aridad: nada comprueba que se pasen todos los argumentos requeridos, ni que no sobren. La cuarta es el escapado, el más silencioso de todos: un valor con una barra, un espacio o un acento rompe la ruta o la trunca, y el fallo depende de los datos y no del código, así que aparece en producción y no en desarrollo.

// El patron y su construccion viven separados y nada los relaciona.
composable("detalle/{productoId}?origen={origen}") { entrada ->
    val id = entrada.arguments?.getString("productoId")   // puede ser nulo
    PantallaDetalle(id!!)                                  // y aqui se paga
}

navController.navigate("detalle/${producto.id}?origen=catalogo")

Los cuatro fallos comparten una firma reconocible: se manifiestan lejos de donde se originan y siempre en ejecución. El compilador ha visto pasar dos cadenas de texto perfectamente válidas y no tenía manera de saber que una pretendía ser el molde de la otra.

flowchart LR
subgraph Antes
  A1[Clase de datos con campos] --> A2[Se aplasta a una cadena]
  A2 --> A3[Viaja sin tipo]
  A3 --> A4[Se reconstruye a mano]
  A4 --> A5[Fallo en ejecucion]
end
subgraph Ahora
  B1[Clase serializable] --> B2[Viaja como valor]
  B2 --> B3[El compilador verifica]
  B3 --> B4[Se recupera con toRoute]
  style B3 fill:#a6e3a1,color:#11111b
end

Solo el primer fallo se mitiga con disciplina, extrayendo constantes y funciones auxiliares. Los otros tres son consecuencia de haber elegido un tipo sin estructura para representar algo que la tiene, y por eso ninguna cantidad de cuidado los elimina.

Destinos como valores

La propuesta con tipos seguros invierte el planteamiento: en lugar de describir el destino con un patrón y rellenarlo, se declara una clase serializable por destino y se navega pasando una instancia.

@Serializable
object Catalogo

@Serializable
data class Detalle(val productoId: String, val origen: String = "catalogo")

@Serializable
data class Resultados(val consulta: String, val pagina: Int = 1)

Un destino sin argumentos es un object; uno con argumentos es una data class cuyos campos son los argumentos. No hay patrón que escribir, ni nombres que repetir, ni tipos que declarar aparte: la firma del constructor ya lo dice todo.

NavHost(navController, startDestination = Catalogo) {
    composable<Catalogo> {
        PantallaCatalogo(alPulsar = { id -> navController.navigate(Detalle(id)) })
    }
    composable<Detalle> { entrada ->
        val args: Detalle = entrada.toRoute()
        PantallaDetalle(productoId = args.productoId, origen = args.origen)
    }
}

Conviene ver con precisión qué acaba de cambiar. navigate ya no recibe texto sino un valor, así que un identificador de tipo equivocado no compila y un argumento que falta tampoco. composable se parametriza por el tipo del destino, de modo que registrar un destino y navegar hacia él comparten una única fuente de verdad. Y toRoute devuelve una instancia reconstruida, con lo que dentro de la pantalla los argumentos son campos de un objeto y no consultas a un mapa que podrían devolver nulo.

La serialización sigue existiendo, porque la pila tiene que sobrevivir a la muerte del proceso y un enlace profundo tiene que ser una cadena de texto. Lo que ha cambiado es quién la hace: antes la escribías tú en cada llamada, ahora la genera el compilador a partir de la declaración. El escapado, la conversión y la reconstrucción dejan de ser código tuyo, y con ellos desaparecen las tres categorías de fallo que la disciplina no podía cubrir.

Argumentos que no son cadenas ni enteros

Los tipos primitivos y sus versiones nulas se soportan directamente. Lo interesante empieza justo después, y hay tres casos que aparecen en cualquier aplicación real.

@Serializable
enum class Orden { RECIENTES, PRECIO, VALORACION }

@Serializable
data class Busqueda(
    val consulta: String,
    val orden: Orden = Orden.RECIENTES,
    val categoriaId: String? = null,
)

Una consecuencia que se agradece pronto es que el destino inicial deja de ser una cadena y pasa a ser un valor, con lo que puede llevar argumentos calculados al montar el grafo. Y otra, menos visible pero más útil a largo plazo, es que añadir un argumento obligatorio a un destino rompe la compilación exactamente en los puntos desde los que se navega hacia él, que son justo los que hay que revisar.

Sobre los tipos propios conviene una advertencia de diseño que pesa más que la técnica: el hecho de que se pueda pasar un objeto complejo no significa que se deba. Un argumento de navegación forma parte de una estructura que se serializa, se guarda en disco y a veces se publica como enlace. Pasar un objeto de dominio entero acopla el formato guardado a la forma de tu modelo, multiplica el tamaño de lo que se archiva y garantiza que cualquier cambio del modelo rompa estados guardados de la versión anterior.

La migración de un grafo existente no exige una operación de todo o nada, y conviene saberlo porque el temor a lo contrario es lo que la retrasa. Ambas formas de declarar destinos conviven en el mismo grafo, así que se puede convertir un destino cada día y mantener el proyecto compilando entre paso y paso. El orden que menos fricción produce es empezar por las hojas, los destinos a los que se navega pero desde los que no se navega, porque cada conversión toca solo los puntos de llamada y no el interior de otras pantallas.