Deja de Escribir Tus Rutas

Entonces sí, mi nombre es Eduardo. Buenos días, Londres. Feliz de estar aquí otro año. Así que como miembro de Querty pero también como desarrollador y amante del código abierto, he estado haciendo mucho desarrollo de bibliotecas, casi durante siete años creo. Así que no solo PNIA y Vue Router sino también algunas de las bibliotecas que están justo al lado de Vue en sí. Y he estado pasando bastante tiempo pensando en cómo diseñamos las APIs para estas bibliotecas. A veces metiendo la pata, cometiendo errores, a veces mejorándolos después, por supuesto. Pero el punto es que diseñar una API es realmente difícil, ¿verdad? Y creo que no hace falta decir que esto es uno de los mayores desafíos de cualquier biblioteca de código abierto porque tienes que considerar muchas cosas, lo siento, tienes que tener en cuenta muchos factores diferentes. Es desde cómo cambian estas API, espera, lo siento, necesito cambiar la cosa. Esto va a ser doloroso. Vale. Así que tienes que tener en cuenta muchos factores diferentes desde, espera, mi software se rompió aquí y creo, ¿cómo lo hago? Vale, tengo que hacer todo de memoria. Dios, no tener ninguna nota cuando, se supone que debemos tener notas, es muy difícil. Así que tienes que tener en cuenta muchas cosas diferentes. ¿Vale? Tienes que considerar los usuarios que tienes, ¿estás construyendo una nueva API? ¿No estás construyendo una nueva API? Y cómo se siente la API para los usuarios, porque al final, que una API sea buena o mala es muy subjetivo. Y voy a mostrarles por qué. Así que una de las cosas que siento que es muy importante para una buena API es hacer que los errores sean difíciles de cometer. Ahora, puede ser obvio para algunos y completamente nuevo para otros, pero si usas una biblioteca donde cometer errores es fácil, te hace sentir tonto. Ahora, a nadie le gusta sentirse tonto cuando están usando algo, ¿verdad? Así que definitivamente es un gran factor en mi opinión de cómo una API puede ser buena o no. Otra gran cosa es evitar el cambio de contexto. Ahora, cuando pensamos en las APIs, primero pensamos en el código que necesitamos escribir. Pero si la API real va más allá del código que escribimos, no es solo los archivos, la carpeta que tenemos, sino que podemos pensar en muchas otras cosas que son parte de la API porque cuando escribimos código, cuando desarrollamos un programa, no estamos solo escribiendo el código en sí. Y luego tenemos que adaptarlo para diferentes experiencias de usuario.

Ahora, esto es muy vago para ser honesto, pero no es lo mismo escribir una V1 de una API, donde solo tienes nuevos usuarios, que escribir una V2 de una API donde tienes usuarios existentes que están acostumbrados a algo. Además, tienes que pensar en bien, ¿en qué idioma estás escribiendo no es lo mismo escribir una API en Java o Rust, que en JavaScript o TypeScript donde las cosas están evolucionando muy rápido. Y me gusta referirme a esta pequeña broma, la curva de aprendizaje del usuario. Entonces, la cosa es que nuestra experiencia al aprender algo, que también es parte de una API, el proceso de aprendizaje es diferente y es subjetivo. Entonces, la broma

Tienes como el tiempo recientemente y luego cuánto puedes hacer con una herramienta. Así que, como puedes ver, Notepad, puedes usarlo muy rápidamente y no eres muy eficiente. Luego tienes Pico, que es solo una herramienta basada en terminal y puedes hacer un poco más de cosas. Luego tienes Visual Studio, donde aprendes muchos atajos, creo, y creo que la broma es que luego empiezas a profundizar demasiado en el IDE y pasas demasiado tiempo haciendo cosas y luego te vuelves menos productivo. Y luego tienes Vee o Veeam o Nveam, que básicamente necesitas aprender mucho antes de siquiera poder usarlo, pero luego eres muy productivo. Y luego tienes Emacs y Spacemacs, que doblan el tiempo y el espacio, creo, porque no hay manera de hacer eso en matemáticas. Y así voy a usar esto como base para lo que llamo ergonomía de las API.

Ahora, la ergonomía de las API, la defino como la frecuencia con la que usas una función, siendo la función un concepto muy vago y abstracto, ¿de acuerdo? Y con qué frecuencia o qué tan fácil es para ti adivinar cómo usar esa función. ¿Has usado antes o no, tienes que tener en cuenta todas estas cosas.

Ahora, podrías imaginar que esto es algo lineal. Por supuesto, no lo es. Y definitivamente no es el objetivo de tener este tipo de ergonomía de las API siendo lineal. En realidad, cuando creo que es mejor, bueno, por supuesto, el mejor escenario es tener algo que vaya así. Pero como puedes imaginar, eso realmente no es posible en la vida, ¿verdad? Así que, tenemos que tener algunos compromisos aquí. Y creo que esto es algo, quiero decir, este gráfico, esta línea ergonómica tiene más sentido y es realmente buena.

Ahora, si lo comparas con el otro aquí, podemos ver que vamos a pasar mucho tiempo haciendo las tareas que son fáciles de hacer, fáciles de adivinar. Así que, esto nos hace sentir más inteligentes porque podemos descubrir las cosas por nosotros mismos. Así que, en términos de la experiencia que estamos desarrollando en nuestra biblioteca, es mucho más interesante. Por otro lado, cualquier cosa que sea bastante compleja, un caso límite, cosas que no haces tan a menudo, tal vez haces un proyecto dos veces, así que tal vez una vez al año o menos, esos van a requerir más trabajo, tal vez usando diferentes APIs, diferentes opciones combinando múltiples cosas en la propia biblioteca para hacer que las cosas funcionen. No tienes una opción como en Nux donde simplemente haces SSR true y tienes SSR, donde simplemente haces view, ¿verdad? Tienes que configurar el servidor V, tienes que configurar muchas cosas.

Ahora, no estoy diciendo que Nux aquí sea malo, todo lo contrario, pero creo que hay un compromiso aquí que se debe encontrar y que si hacemos que las funciones comunes sean fáciles de lograr y fáciles de recordar, estamos ganando mucho al final del día. Así que hoy, quiero explorar este camino borrando una API. Y realmente quiero decir borrar, así que esto no es un cambio radical. No estamos eliminando, ¿de acuerdo? No estamos quitando. Estamos borrando. Y quiero mostrarte un enrutador de vista como ejemplo. Y quiero centrarme en tres cosas. Quiero mantener las cosas juntas, así que esto es para reducir el cambio de contexto. Quiero reducir la repetición, así que solo para iterar más rápido, para poder escribir más en menos tiempo. Y quiero mejorar la experiencia de desarrollo haciendo que los errores sean más difíciles de cometer o más fáciles de detectar ambas cosas al mismo tiempo. Ahora, creo que el enrutamiento o el enrutador es un buen lugar para hacer eso porque el enrutamiento en sí es ampliamente malentendido. Y, honestamente, no culpo a nadie que no entienda bien el enrutamiento porque es la tierra de APIs en constante cambio en el navegador. Como, ¿usamos hash? Solíamos hacer URLs con hash. Ahora, ya no lo hacemos. Es malo para el SEO.

analizar las URLs que son totalmente válidas y ambas funcionan y tal vez incluso puedas usar ambas al mismo tiempo. Por cierto, ni siquiera tienen la URL en el nombre de la API, sph-state. Si tienes historial, pero aún así. Y luego tienes múltiples formas de analizarlo como location.href y luego el constructor de URL tendrá parámetros de búsqueda de URL. Tenemos diferentes eventos y incluso tenemos próximas APIs que, como puedes imaginar, no son compatibles con todos los navegadores como Safari no tiene una palabra sobre estas API que han estado en una discusión en curso durante dos años ya. Así que, ni siquiera sabemos a dónde ir. Al menos, ya no tenemos Internet Explorer, pero aún así.

Así que, además de eso, es donde muchas de las diferentes cosas o tu aplicación se juntan, el enrutamiento. Así que, tienes estado en la URL. Tienes la interfaz de usuario con transiciones o animaciones que pueden ocurrir entre las páginas. Y luego tenemos el modelo como con la obtención de datos, generalmente se integra eso con el enrutamiento. Y tenemos un montón de vocabulario, ¿de acuerdo? Y esto puede parecer nada, pero cuando tienes que recordar la palabra correcta cuando estás buscando la documentación, hace una gran diferencia porque no puedes encontrar la ayuda real en la documentación. Así que, se vuelve muy frustrante. Y además de eso, tenemos un comportamiento propenso a errores. Por ejemplo, defines rutas de esta manera teniendo un camino y nombre y luego puedes empujar con un nombre y puedes empujar con una cadena. Pero ¿qué era antes? ¿Era slash about, era about? Y no vas a obtener ningún error cuando estás escribiendo este código hasta que vayas al navegador, así que cambias de contexto, ves el error en la consola diciendo, oye, no hay nombre de ruta slash about. Y ni siquiera te dice si hay otro nombre de ruta about. Así que, ¿podemos simplificar todo esto? Por supuesto, no estaría hablando aquí si no pudiéramos simplificar esto. Y quiero centrarme en una parte muy simple del enrutamiento que es crear rutas, es el comienzo de cualquier aplicación SPA. Ahora, cuando creas una ruta, usualmente creas un archivo. Esto es algo que podemos fusionar juntos. Y creo que esto va a ser familiar para muchos de ustedes. Y estamos como borrando la creación de la ruta, creando el objeto, el registro de ruta. El problema que surge antes es que todavía necesitamos configurar las rutas, pero ya no estamos escribiendo la configuración. Entonces, ¿cómo manejamos eso?

Y así, quiero hacer una pequeña demostración rápida, ¿quién ha usado enrutamiento basado en archivos antes? Bien, casi todos... Oh, hay una gran diferencia en ambos lados. Más de la mitad de las personas aquí. Así que, el enrutamiento basado en archivos es lo que te permite definir estos arrays de rutas o incluso la ruta por completo. El enrutador, lo siento, por completo. Simplemente teniendo una estructura de carpetas.

Entonces, cuando tenemos enrutamiento basado en campos, lo que tenemos y lo que es muy importante es que tenemos un mapeo predecible uno a uno. Entonces, sabemos y tenemos algunas reglas que quizás aprendemos una vez. Sabemos que index dot view, index dot HTML simplemente se convierte en una barra al final. Y sabemos que incluso tenemos los corchetes, se convierte en un parm. Y lo bueno es que porque esto está justo al lado de ti en tus archivos, en tu editor, ves esto todos los días. Entonces, realmente no necesitas aprender esto varias veces, ¿verdad? Lo aprendes una vez y luego está en tu cabeza, está ahí. Y porque tenemos un mapeo uno a uno, podemos dejar que todas las herramientas generen el código pegamento para que podamos escribir solo la parte interesante, idealmente.

Ahora, esto incluye los registros de ruta e importaciones que son algo de código repetitivo. Pero también, podemos tener tipos que podríamos escribir manualmente pero que se van a generar por sí mismos, por lo que siempre son correctos. Y también, otras metas de ruta y otras cosas que son código más allá de eso. Entonces, la idea aquí es que queremos obtener un error si escribimos algo como esto. Y no queremos el clásico error de TypeScript cuando dice que la cadena no es asignable al tipo A. Luego tienes tres puntos en los que ni siquiera puedes hacer clic. Y luego, tienes algo como nunca no es asignable a cadena. Y ni siquiera sabes qué pasó en medio. Idealmente, quieres un error preciso que te diga, oye, a este objeto le falta la propiedad ID, ¿verdad? Este nombre no existe. Esta condición no es posible. Entonces, estos son tipos y errores, ¿vale? Este parámetro otro no existe para esta ruta porque comprobamos que el nombre es ID por lo que la forma del parámetro es un objeto con un ID. Y entonces, inicialmente, quería hacer esto con tipo, con tipos de tiempo de ejecución que, es una característica muy interesante de TypeScript. Entonces, tienes lo que llamamos cadenas literales que en realidad podemos analizar y podemos transformar objetos en tipos reales. Todo esto funciona, ¿vale? Y lo hice... Entonces, lo bueno es que simplemente necesitas tomar tu array de rutas, pones esto como const al final, y luego puedes generar un objeto que contiene todos los parámetros para cada ruta con nombre. Ahora, el problema es que esto es realmente lento. Y me llevó algún tiempo probarlo porque cuando empecé a hacerlo empiezas con unas pocas rutas. Pero luego cuando llegué a 50, me di cuenta de que no logré nada más que hacer que el servidor de TypeScript se bloqueara, lo cual puede ser un logro en sí mismo, pero no es lo que quiero para mi vida diaria en el desarrollo. Y además de eso, tengo

Así que aquí está la macro de página definida, que, bueno, sé que estamos haciendo muchas macros aquí, define, define, define algo, así que solo otra para recordar, pero la idea es que puedes pasar todas las propiedades que estás usando en la configuración de la ruta, en las rutas La diferencia es que estamos en la página, por lo que no hay cambio de contexto, nos estamos quedando en el mismo componente, estamos definiendo cosas. Y podemos agregar cualquier cosa que queramos. También podemos tener bloques JSON, o Yaml, u otras cosas si quieres. Y entonces, lo genial es que porque esto va a afectar a los tipos reales, si lo cambias aquí, así que voy a definir la página y cambiar el nombre de esta ruta a algo más. Así que estoy cambiando mi propio nombre aquí, voy a guardar, y voy a obtener un error aquí porque este nombre ya no existe. Así que obtienes una retroalimentación instantánea así, y luego lo cambio solo para hacer que coincida. Bueno, cerrando ese capítulo, hay otras cosas que podemos hacer para mejorar las APIs. Una de ellas es la carga de data. Ahora, la carga de data es un tema enorme. Pero hoy tenemos diferentes formas de manejarlo, y esta es, en mi opinión, una de las razones por las que no es una gran API en este momento. O si hay una API, si no hay una API única. Así que tenemos diferentes formas de hacerlo. Tenemos watch en los parámetros, pero no tenemos solo estado, no errores, no manejo de SSR. Tenemos todos los guardias de navegación, pero se duplican, y puede ser verboso, y definitivamente no está tipado, excepto con el plugin, por supuesto. Luego tenemos guardias de navegación globales, que pueden permitirte crear una solución personalizada de data, y diría que esta es la solución más conveniente. Y luego tenemos suspense, que tengo una diapositiva entera para ellos de todos modos. Pero todos tienen problemas. Todos presentan algunos problemas que no nos permiten usarlos como solución de obtención de data. Así que suspense en la superficie es simplemente perfecto. Solo ponemos un weight en el script. No hay nada tan simple como eso. Y tiene algunas ventajas, como que es muy sencillo de escribir, el más sencillo de escribir,

Muchas gracias, Eduardo. Eso fue extremadamente interesante. Y me encanta el design de tus diapositivas. Son como super sexy. Bueno. Así que, vamos a revisar las preguntas. Pero antes la primera de todos, ¿puedes usar rutas tipadas sin enrutamiento basado en archivos?

Sí, puedes usar las rutas tipadas sin enrutamiento basado en archivos pero la idea es que estás dividiendo la generación de los tipos y la escritura de las rutas por lo que tienes algo de trabajo manual que hacer, mientras que el punto de tener este enfoque es que los tipos son automáticos y no necesitas preocuparte por ello, por lo que es menos probable que cometas errores, es menos propenso a errores.

Ok, definitivamente tiene sentido.

Ok, entonces vamos a ver lo que tenemos aquí, ¿este plugin soporta Vue 2?

Vue 2? No, no soporta Vue 2 porque los tipos en el router son bastante diferentes por lo que sería una gran, es más una cuestión de tiempo, simplemente no tengo suficiente tiempo para hacer que soporte Vue 2 en este momento.

Ok, ¿quizás en el futuro o? O incluso, dudo que pueda encontrar el tiempo para hacerlo en el futuro pero invito a cualquiera a copiar el código y hacer un fork para Vrouter 2, definitivamente.

Ok, lo has oído, una oportunidad de código abierto.

Entonces, la siguiente, ¿cómo deberíamos manejar las rutas protegidas con enrutamiento basado en archivos?

Así que las rutas protegidas, normalmente creas un guardia de navegación, por lo que todavía crearías tu propio guardia de navegación, de la misma manera. Tienes la instancia del router en algún lugar, así que simplemente router antes de cada uno o antes del resultado. Hay otros patterns que puedes usar con Metafields, puedes definir Metafields en las rutas, eso te permite tener guardias de navegación bastante finos aplicados a múltiples rutas. Así que un solo guardia de navegación que se aplica en múltiples páginas.

OK, genial. Creo que es un poco más difícil de explicar sin un código.

Genial, tiene sentido.

La siguiente es, ¿hay alguna posibilidad de que la funcionalidad de desenchufar ViewRouter se convierta en parte de Sí, probablemente iremos, quiero decir, para hacer eso tenemos que pasar por un RFC primero. La diferencia es que no es, quiero decir que la mayoría del código no es en tiempo de ejecución, ¿verdad? La mayoría del código está incorporado. Así que todavía viene como algo que estará un poco al margen, así que si se convierte en parte de u-router todavía será como un plugin vid que se expone a través de una ruta diferente como u-router slash plugin o algo así.

Ok, genial.

La siguiente es, ¿puedes definir los cargadores en un archivo separado y luego importarlo en múltiples componentes?

Sí, sólo necesitas exportar el cargador desde la página para decirle al router que esta página está utilizando ese cargador. Eso es todo. Y luego usas el composable en cualquier lugar. Entonces, ¿necesitas importar primero el cargador y luego exportar esa importación?

Sí, también puedes hacer simplemente exportar. No lo dije pero tienes dos scripts, tienes el script regular y luego el script de configuración. Así que en el script regular, es donde puedes exportar cosas, y es donde puedes simplemente hacer exportar algo de algo más o puedes importarlo y luego exportarlo porque todavía necesitarás importarlo en la configuración si no lo importas en el otro script. El editor facilita mucho conseguir el comportamiento correcto porque simplemente autocompleta.

Ok, definitivamente tiene sentido.

Y la última pregunta es, ¿no terminaremos con docenas de archivos index.vue e id.vue? ¿Cuándo? O no, ¿no terminaremos con docenas de archivos index.vue e id.vue? Sí, probablemente, pero no necesariamente. Depende si tienes otras rutas que tienen la misma ruta común, pero aún buscas la ruta por el otro nombre. Si tienes una página de usuarios y un usuario / nuevo, tienes un usuario / index y un usuario / nuevo.vue. Entonces, cuando buscas los archivos, buscas el índice de usuarios, o probablemente uses mi espacio de usuario ei, lo siento. Cuando haces un Control-P en tu VSCode, aún encontrarás tu camino muy fácilmente, porque aún tienes la estructura de carpetas que prevalece. OK, sí. Es más como nodos en un árbol en comparación con las hojas. Entonces, las hojas se parecen entre sí, pero los nodos no. OK, perfecto. Muchas gracias, Eduardo. Y siéntete libre de hacer más preguntas arriba en la parte de preguntas y respuestas de los oradores. Y sí, danos un aplauso.