Cuanto más trabajas en una aplicación, más complicado se vuelve su enrutamiento y más fácil es cometer un error. "¿Se llamaba la ruta usuarios o usuario?", "¿Tenía un parámetro id o era userId?". Si solo TypeScript pudiera decirte cuáles son los nombres y parámetros posibles. Si solo no tuvieras que escribir una sola ruta más y dejar que un complemento lo haga por ti. En esta charla repasaremos lo que se necesitó para traer rutas automáticamente tipadas para Vue Router.
Versión en Español
Video Summary and Transcription
Diseñar APIs es un desafío y es importante considerar el lenguaje utilizado y las diferentes versiones de la API. La ergonomía de la API se centra en la facilidad de uso y los compromisos. El enrutamiento es un aspecto mal entendido del diseño de la API y el enrutamiento basado en archivos puede simplificarlo. Desconectar View Router proporciona rutas tipadas y elimina la necesidad de pasar rutas al crear el enrutador. La carga y manipulación de datos se pueden mejorar con cargadores de datos y rutas predecibles. También se discuten las rutas protegidas y los archivos de índice e ID.
Available in English
1. Diseño de APIs: Desafíos y Consideraciones
Short description:
Diseñar una API es realmente difícil. Es uno de los mayores desafíos de cualquier biblioteca de código abierto. Una buena API dificulta cometer errores y evita cambios de contexto. Es importante escribir diferentes versiones de una API y considerar el lenguaje utilizado. El proceso de aprendizaje de una API es subjetivo.
Así que sí, mi nombre es Eduardo. Buenos días, Londres. Feliz de estar aquí otro año. Como miembro de Querty pero también como desarrollador y amante del código abierto, he estado desarrollando muchas bibliotecas, casi durante siete años, creo. No solo PNIA y Vue Router, sino también algunas de las bibliotecas que son adyacentes a Vue en sí. Y he estado dedicando mucho tiempo a pensar cómo diseñar las APIs para estas bibliotecas. A veces, cometiendo errores, mejorándolos después, por supuesto. Pero lo más importante es que diseñar una API es realmente difícil, ¿vale? Y creo que no hace falta decir que este es uno de los mayores desafíos de cualquier biblioteca de código abierto porque tienes que tener en cuenta muchos factores diferentes. Desde cómo cambia esta 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 pienso, ¿cómo lo hago? Vale, tengo que hacer todo de memoria. Dios, no tengo ninguna nota cuando, se supone que debemos tener notas, muy difícil. Así que tienes que tener en cuenta muchos factores diferentes. ¿Vas a tener en cuenta a 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, una API buena o mala es muy subjetiva. Y te voy a mostrar por qué. Así que una de las cosas que considero muy importante en una buena API es que sea difícil cometer errores. 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á usando algo, ¿verdad? Así que definitivamente es un factor importante en mi opinión de cómo puede ser buena o no una API. Otro gran aspecto 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 solo los archivos, la carpeta que tenemos, sino que también podemos pensar en muchas otras cosas que forman parte de la API porque cuando escribimos código, cuando desarrollamos un programa, no solo estamos escribiendo código en sí. Y luego tenemos que adaptarlo a 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. También tienes que pensar en qué lenguaje estás escribiendo, no es lo mismo escribir una API en Java o Rust que en JavaScript o TypeScript, donde las cosas evolucionan muy rápido. Y me gusta referirme a esta pequeña broma, la curva de aprendizaje del usuario. Entonces, lo que sucede es nuestra experiencia al aprender algo, que también es parte de una API, el proceso de aprendizaje es diferente y es subjetivo. Así que, la broma
2. Diferentes Herramientas y Ergonomía de API
Short description:
Diferentes herramientas tienen diferentes niveles de eficiencia y productividad. Notepad es rápido pero no eficiente. Pico permite más funcionalidad. Visual Studio tiene muchos atajos pero puede disminuir la productividad. Vee, Veeam y Nveam requieren aprendizaje pero resultan en alta productividad. Emacs y Spacemacs son herramientas poderosas. Esto forma la base de la ergonomía de la API.
Aquí es muy simple en realidad. Tienes algo así como el tiempo reciente y luego cuánto puedes hacer con una herramienta. Entonces, 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 poder usarlo en absoluto, pero luego eres muy productivo. Y luego tienes Emacs y Spacemacs, que doblan el tiempo y el espacio, creo, porque no hay forma de hacer eso en matemáticas. Y así
3. API Ergonomics and Erasing APIs
Short description:
La ergonomía de la API se trata de qué tan a menudo y qué tan fácil es usar una función. No es lineal, pero se requieren compensaciones. Las funciones comunes deben ser fáciles de lograr y recordar. Hoy, exploraré cómo borrar una API y me enfocaré en mantener las cosas juntas, reducir la repetición y mejorar la experiencia de desarrollo. El enrutador es un buen lugar para hacer esto, ya que el enrutamiento es ampliamente mal entendido.
Voy a usar esto como base para lo que llamo ergonomía de la API. Ahora, la ergonomía de la API, la defino como qué tan a menudo usas una función, siendo la función un concepto muy vago y abstracto, de acuerdo. Y qué tan a menudo o qué tan fácil es para ti adivinar cómo usar esa función. Si la 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 esta ergonomía de API lineal. En realidad, cuando pienso que es mejor, bueno, por supuesto, el mejor escenario es tener algo así. Pero como puedes imaginar, eso realmente no es posible en la vida, ¿verdad? Así que tenemos que hacer algunos compromisos aquí. Y creo que esto es algo, quiero decir, esta gráfica, esta línea ergonómica tiene más sentido y es realmente buena. Ahora, si la comparamos con la otra aquí, podemos ver que vamos a pasar mucho tiempo haciendo las tareas que son fáciles de hacer, fáciles de adivinar. Esto nos hace sentir más inteligentes porque podemos descubrir las cosas por nosotros mismos. Entonces, 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 especial, cosas que no haces con frecuencia, tal vez hagas un proyecto dos veces, tal vez una vez al año o menos, eso va a requerir más trabajo, tal vez usando diferentes API, diferentes opciones combinando múltiples cosas en la propia biblioteca para que las cosas funcionen. No tienes una opción como en Nux donde solo haces SSR true y tienes SSR, donde solo haces vista, ¿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 que se puede 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 que rompa. No estamos eliminando, ¿de acuerdo? No estamos eliminando. Estamos borrando. Y quiero mostrarte un enrutador de vista como ejemplo. Y quiero enfocarme en tres cosas. Quiero mantener las cosas juntas, para reducir el cambio de contexto. Quiero reducir la repetición, para iterar más rápido, 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í mismo es ampliamente mal entendido. Y, sinceramente, no culpo a nadie que realmente no entienda bien el enrutamiento porque es el terreno de APIs en constante cambio en el navegador. Como, ¿usamos hash? Solíamos usar URLs con hash. Ahora,
4. Challenges of Routing and File-based Routing
Short description:
Múltiples formas de analizar las URL, diferentes eventos y próximas API, y los desafíos del enrutamiento en una aplicación. Comportamiento propenso a errores y la necesidad de simplificación. El enrutamiento basado en archivos como solución.
ya no lo hacemos. Es malo para SEO. Y luego tenemos, debido a eso, múltiples formas de analizar las URL 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 API que, como puedes imaginar, no son compatibles con todos los navegadores como Safari no tiene una palabra sobre estas API que han estado en discusión durante dos años ya. Entonces, ni siquiera sabemos a dónde ir. Al menos, ya no tenemos Internet Explorer, pero aún así. Además de eso, es donde muchas de las cosas diferentes de tu aplicación se unen, el enrutamiento. Entonces, 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 con el enrutamiento. Y tenemos un montón de vocabulario, ¿de acuerdo? Y esto puede parecer insignificante, pero cuando tienes que recordar la palabra correcta cuando estás buscando en la documentación, marca una gran diferencia porque no puedes encontrar la ayuda real en la documentación. Entonces, se vuelve muy frustrante. Y además de eso, tenemos un comportamiento propenso a errores. Por ejemplo, defines las rutas de esta manera teniendo una ruta y un nombre y luego puedes hacer push con un nombre y puedes hacer push con una cadena. Pero ¿qué era antes? ¿Era slash about, era about? Y no obtendrás ningún error cuando escribas este código hasta que vayas al navegador, entonces cambias de contexto, ves el error en la consola que dice, hey, no hay una ruta con el nombre slash about. Y ni siquiera te dice si hay otra ruta con el nombre about. Entonces, ¿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 una ruta, es el comienzo de cualquier aplicación SPA. Ahora, cuando creas una ruta, generalmente creas un archivo. Esto es algo que podemos fusionar. Y creo que esto les resultará familiar a muchos de ustedes. Y estamos borrando la creación de la ruta, la creación del objeto, el registro de la ruta. El problema que surge antes es que aún necesitamos configurar las rutas, pero ya no estamos escribiendo la configuración. Entonces, ¿cómo lo manejamos? Y así, quiero hacer una pequeña muestra rápida de manos, ¿quién ha utilizado el enrutamiento basado en archivos antes? Ok, casi todos... Oh, hay una gran diferencia en ambos lados. Más de la mitad de las personas aquí. Entonces, el enrutamiento basado en archivos es lo que te permite definir este array de rutas o incluso el
5. Enrutamiento basado en campos y manejo de errores
Short description:
Nuxt elimina por completo la creación del enrutador, abogando por reducir la repetición de código manteniendo la flexibilidad. El enrutamiento basado en campos proporciona un mapeo predecible y elimina la necesidad de aprender múltiples veces. Las herramientas pueden generar código de unión, lo que permite a los desarrolladores centrarse en la parte interesante. Los tipos y errores son cruciales, buscando errores precisos en lugar de genéricos. Los tipos en tiempo de ejecución y las cadenas literales pueden transformar objetos en tipos reales. Generar parámetros para cada ruta puede ser lento y dar como resultado un código ilegible.
ruta en absoluto. El enrutador, perdón, en absoluto. Solo con tener una estructura de carpetas. Ahora, esto es lo que hace Nuxt. Elimina por completo la creación del enrutador. Y quiero mostrarte algo similar y quiero abogar un poco más por ello. Entonces, la idea y el punto clave aquí es que necesitamos una forma de reducir la repetición de código, que es lo que está sucediendo aquí, sin comprometer la flexibilidad, que es poder configurar las rutas.
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. Sabemos y tenemos algunas reglas que tal vez aprendamos una vez. Sabemos que index.view, index.HTML simplemente se convierte en una barra al final. Y sabemos que incluso tenemos los corchetes, se convierte en un parámetro. Y lo bueno es que porque esto está justo al lado tuyo en tus archivos, en tu editor, ves esto todos los días. Entonces, realmente no necesitas aprender esto varias veces, ¿de acuerdo? Lo aprendes una vez y luego lo tienes en tu cabeza, está ahí. Y debido a que tenemos un mapeo uno a uno, podemos dejar que todas las herramientas generen el código de unión para que podamos escribir solo la parte interesante, idealmente.
Ahora, esto incluye los registros de ruta y las importaciones, que es algo así como un código repetitivo. Pero también podemos tener tipos que podríamos escribir manualmente pero vamos a generarlos automáticamente, por lo que siempre son correctos. Y también, otros metadatos 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 que dice que una cadena no se puede asignar a un tipo A. Luego tienes tres puntos que ni siquiera puedes hacer clic. Y luego, obtienes algo como que nunca se puede asignar a una cadena. Y ni siquiera sabes qué sucedió en el medio. Idealmente, quieres un error preciso que te diga, oye, este objeto no tiene la propiedad ID, ¿verdad? Este nombre no existe. Esta condición no es posible. Entonces, estos son tipos y errores, ¿de acuerdo? Este parámetro 'other' no existe para esta ruta porque verificamos que el nombre es ID, por lo que la forma del parámetro es un objeto con un ID. Y así, inicialmente, quería hacer esto con tipos en tiempo de ejecución, que es una característica muy interesante de TypeScript. Entonces, tenemos lo que llamamos cadenas literales que realmente podemos analizar y podemos transformar objetos en tipos reales. Todo esto funciona, ¿de acuerdo? Y lo hice... Entonces, lo bueno es que solo necesitas tomar tu matriz de rutas, poner esto como constante al final, y luego puedes generar un objeto que contenga todos los parámetros para cada ruta con nombre. Ahora, el problema es que esto es realmente lento. Y me llevó un tiempo probarlo porque cuando comencé a hacerlo, comienzas con unas pocas rutas. Pero luego, cuando llego a 50, me doy cuenta de que no logro nada más que hacer que el servidor de TypeScript se bloquee, lo cual puede ser un logro en sí mismo, pero no es lo que quiero en mi vida diaria de desarrollo. Y además de eso, tengo
6. Desconectando View Router: Conceptos básicos y Rutas tipadas
Short description:
He escrito muchos lenguajes como C y Prolog, pero nada se compara con este código. Me di cuenta de que tenía que volver a lo básico y crear un tipo que asocie una ruta a tipos. Desconectando View Router es una biblioteca que funciona con diferentes herramientas y proporciona rutas tipadas. Ya no es necesario pasar la ruta al crear el enrutador.
decir que este es el código más ilegible que he escrito en toda mi vida. Y he escrito muchos lenguajes como C y Prolog, si conoces este lenguaje. Así que he escrito código ilegible muchas veces. Pero nada se compara con este código. Y realmente intenté muy duro hacer que algunas cosas fueran legibles aparte de los genéricos de una sola letra, que es solo parte de la vida con LifeScript. Y no estoy realmente avergonzado, empeora aún más, ¿de acuerdo? Pero te invito a que simplemente revises el enlace y seas testigo de la magia completa de Turing de TypeScript aquí. No voy a profundizar en los tipos, por supuesto, no tiene sentido. Lo que sucede es que me di cuenta de que tenía que volver a lo básico. Tenemos que volver a algo que no aplaste a TypeScript y que sea más fácil de entender, que pueda ser legible para los humanos aunque nos estemos convirtiendo en cosas de IA. Entonces, ¿cuál es el tipo más básico que podemos tener para asociar una ruta a tipos? Entonces tenemos el tipo params y cosas así. Y si especificamos el nombre como clave y luego tenemos algún tipo de objeto que define las diferentes propiedades de la ruta. Estos todavía son legibles para los humanos. Y se vuelve muy poderoso porque podemos usar la clave del mapa solo para obtener todos los nombres y luego podemos obtener los parámetros de cada ruta diferente. Ahora, el tipo real es un poco más complejo pero aún es legible. Y lo bueno es que podemos aplicar esto a cualquier otro tipo auxiliar, quiero decir cualquier otro tipo que exista en el enrutador de vista y hacerlos tipados. Entonces, ya no te permiten pasar solo una cadena en el nombre. Se convierte en una unión de muchas cadenas diferentes. Y aquí es donde entra en juego Desconectando View Router Ahora, sé que no es un nombre elegante. No tiene un logotipo lindo como Pina, pero esto es simplemente porque quiero mantenerme lo más cerca posible del nombre de la biblioteca, el propio enrutador de vista y también porque funciona con diferentes cosas, Vite, DRAWLAB, Webpack, etc., etc. Puedes usarlo sin ninguna opción. Ahora, esto no es algo nuevo en sí mismo cuando se trata del enrutamiento basado en archivos. Es algo que ha existido durante mucho tiempo, ¿de acuerdo?, desde 2018, creo, Hattachine, otro miembro del equipo central de VGS, lo hizo. E incluso hoy en día, uno de los complementos más comunes es Vite Plugin Pages de Han, creo. Así que estoy introduciendo otras cosas. Y esto es específico de ViewRouter por algunas razones. La idea aquí, y esta es la parte interesante, es que no solo necesitas cambiar todas las importaciones de ViewRouter a ViewRouter auto. Y esto te dará los tipos que están basados en tus rutas. Entonces, lo bueno es que aún tienes el control. Creas el enrutador pero ya no pasas la ruta, que es la parte grande y repetitiva del enrutamiento, ¿de acuerdo? Ups,
7. Rutas tipadas y Configuración de Rutas
Short description:
Puedes modificar las rutas en tiempo de ejecución o en tiempo de compilación. Al pasar parámetros, puedes tipar de forma segura las rutas y ver errores en tu editor. Al usar useRoute, puedes especificar la ruta específica para una página. La forma en que funciona es generando un archivo DTS de tipo de ruta que te permite configurar mapas de nombres de ruta y anulaciones para tu enrutador y funciones.
lo siento. Eso fue un poco rápido. Aún puedes modificar las rutas. Y esto es el runtime cambiante. Puedes extender las rutas. También puedes hacerlo en tiempo de compilación. Entonces, puedes, en tu configuración V, agregar cualquier ruta y también estarán tipadas. Así que tu código reconocerá todo. ¿Cómo funciona? ¿Cómo se ve? En lugar de simplemente empujar una interpolación de una cadena aquí de una ruta. Este es un ejemplo de Vitess, por cierto. Lo que hacemos aquí es pasar el nombre, que se autocompletará aquí. Así que podemos seleccionar la ruta que queremos y luego podremos agregar el objeto params y ese objeto params nos dirá, oye, te falta un ID aquí. Tan pronto como ponga las llaves. Y así tenemos el autocompletado y no el ID, el nombre. Lo siento. Pero básicamente entiendes la idea. Puedes pasar cualquier parámetro que quieras aquí y estará tipado de forma segura, por lo que no necesitas cambiar al navegador para ver un problema. Lo verás directamente en tu editor. Así que no tienes que cambiar de contexto. Ahí vamos. Y Y luego creo que borré esa línea porque no es buena. Muy bien. Ahora, cuando obtienes la ruta con useRoute, tienes todas las rutas posibles aquí que pueden aparecer en tu aplicación. Pero cuando estamos en una página, esto es name.ui, ve el archivo name app allá arriba. Sabemos que hay un parámetro de nombre en la URL, ¿de acuerdo? Entonces, ¿cómo le decimos a useRoute que esta es la ruta real, estamos seguros de que esta es la ruta alta nombre? Así que podemos pasar un genérico aquí. Así que voy a escribir alta, ese corchete nombre. Y luego la ruta se convierte en una versión específica de la aplicación. Y por supuesto, este genérico, como viste, no se autocompletó. Ahora, creo que lo cambiaron en el reciente TypeScript.
8. Mejora de las APIs: Carga y Manejo de Datos
Short description:
La versión que permite pasar un argumento tiene autocompletado. La forma en que funciona es generando un gran archivo DTS de tipo de ruta que puedes configurar. La clave es no comprometer la flexibilidad al hacer tareas comunes más fáciles. La macro de página definida permite pasar propiedades para la configuración de la ruta. La carga de datos es un tema importante con diferentes opciones de manejo. La observación de los parámetros carece de estado, errores y manejo de SSR. Los guardias de navegación se duplican y se vuelven verbosos. Los guardias de navegación globales ofrecen una solución conveniente. El suspense en la superficie es perfecto, pero tiene algunos problemas de manejo de errores y manejo de SSR.
tal vez cinco. Pero también agregué la versión que te permite pasar un argumento porque esa tiene autocompletado. Así que ni siquiera necesitas pensar demasiado en eso. Ahora, la forma en que funciona es generando un gran archivo DTS de tipo de ruta que puedes configurar, tienes este mapa de nombres de ruta y luego tienes algunos extras, tienes anulaciones de todos los tipos de tu enrutador y funciones. Y luego la idea es, así que estaba hablando antes de cómo estamos haciendo que las cosas que haces muy a menudo sean fáciles de hacer, ¿de acuerdo? Y todas las cosas que son menos comunes, más difíciles. Pero la idea, y la clave, es no comprometer esa flexibilidad. Deberías poder hacer todo lo que podías hacer antes, que es la configuración.
Así que aquí está la macro de página definida, que, bueno, sé que estamos haciendo muchas macros aquí, definir, definir, definir 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 quedamos en el mismo componente, estamos definiendo cosas. Y podemos agregar lo que queramos. También podemos tener bloques JSON, o Yaml, u otras cosas si quieres. Y lo bueno 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 otra cosa. 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 retroalimentación instantánea así, y luego lo cambio solo para que coincida. De acuerdo, cerrando ese capítulo, hay otras cosas que podemos hacer para mejorar las APIs. Una de ellas es la carga de datos. Ahora, la carga de datos es un tema importante. Pero hoy en día 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 observación de los parámetros, pero no tenemos estado, no errores, no manejo de SSR. Tenemos todos los guardias de navegación, pero se duplican, y pueden ser verbosos, y definitivamente no están tipados, excepto con el complemento, por supuesto. Luego tenemos guardias de navegación globales, que te permiten crear una solución personalizada de data, y diría que esta es la solución más conveniente. Y luego tenemos suspenser weight, para los cuales tengo una diapositiva completa 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 el suspense en la superficie es simplemente perfecto. Simplemente ponemos un peso 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,
9. Introducción a los Cargadores de Datos
Short description:
Los cargadores de datos son funciones que devuelven datos y te proporcionan una composición. Proporcionan acceso a datos, estado de carga, errores y manejan SSR. Exportar cargadores permite reutilizarlos y evitar duplicar solicitudes. Los cargadores pueden tener tipos por defecto y se pueden exportar varios cargadores.
para ser honesto. Pero tiene manejo de errores. Y maneja SSR de manera predeterminada. Pero todavía es experimental, aunque debería cambiar pronto. Y lo más importante, no se actualiza al navegar. No está conectado a la navegación. Está conectado a un componente. Pero en realidad, estos son dos conceptos diferentes, aunque pueden estar acoplados si quieres. Y los data están limitados al componente actual. Si quieres usar algo que obtienes en una página, en otros componentes, debes ponerlo en una tienda o pasarlo como una propiedad o inyectarlo como proveedor. Pero tienen algunos problemas. Entonces, lo que quiero presentarte son los cargadores de datos. Los cargadores de datos son simplemente funciones que devuelven datos. ¿De acuerdo? Y luego te devuelven una composición. Esta composición la puedes usar en el mismo componente, pero también en otros lugares. Y te brinda acceso a los datos en sí, pero también al estado de carga, errores y otras cosas. Y maneja SSR, etc., etc. Ahora, la clave aquí es exportar el cargador. En realidad, no necesitas escribir el cargador aquí. Puedes escribirlo en cualquier lugar. Pero debe ser exportado por la página, para que el enrutador sepa que esta página está cargando esta función. ¿De acuerdo? Estos datos. Y luego puedes reutilizarlo de todos modos. Pero esto también significa que estamos evitando completamente las solicitudes duplicadas. Entonces, si obtienes el perfil del usuario en muchos lugares, si usas los datos del usuario en muchos lugares, aún hacemos una sola solicitud. Tenemos paralelización por defecto, pero también puedes hacer que un cargador dependa de otro si quieres. Y tienen tipos de manera asequible, porque solo estás devolviendo los datos. Si no escribimos ningún tipo, seguirá teniendo un tipo por defecto. Puedes tiparlo explícitamente si quieres, pero funciona de manera predeterminada. Y, por supuesto, puedes exportar varios cargadores. Ahora, el tema completo es un poco más extenso y no tengo más tiempo. Ya me he pasado del tiempo asignado. Pero
10. Rutas Predecibles y Menos Código Repetitivo
Short description:
Creamos rutas predecibles con enrutamiento basado en fallos, lo que permite que nuestra herramienta genere tipos automáticamente. Esto crea un entorno con menos propensión a errores y menos código repetitivo, sin necesidad de cambiar de contexto. Consulta las diapositivas en esm.eslash para obtener más información.
Te invito a que consultes el RFC, que aún tiene algo de tiempo. La idea va un poco más allá de eso. Algunas cachés de cliente, alguna caché simple, soporte para Apollo, Yafire, Suba Base, etc. Y aún está en fase experimental. En resumen, lo que dije es que creamos rutas predecibles mediante un enrutamiento basado en fallos, porque tenemos una correspondencia uno a uno y sabemos cómo van las cosas. Y esto permite que nuestra herramienta genere los tipos automáticamente. Por lo tanto, tenemos un entorno con menos propensión a errores, lo siento, porque tenemos los errores, tenemos más probabilidades de no cometer errores sin la finalización. Sé que hoy en día tenemos Copilot, pero aún comete errores y el compilador no. Y así tenemos menos código repetitivo porque no hay una matriz de rutas y no hay cambio de contexto porque aún estamos en la página. Lo siento, fui muy rápido porque realmente me he pasado de tiempo. Aquí tienes algunos enlaces que puedes consultar. Las diapositivas están en esm.eslash, deja de escribir tus rutas, solo las iniciales. Debería ser muy fácil. Y gracias por tu atención.
QnA
Manejo de Rutas de Tipo y Rutas Protegidas
Short description:
Puedes usar rutas de tipo sin enrutamiento basado en archivos, pero requiere trabajo manual y es menos propenso a errores. El complemento no admite Vue 2. El manejo de rutas protegidas con enrutamiento basado en archivos implica crear una guarda de navegación o usar Metafields. La funcionalidad de desenchufar ViewRouter puede convertirse en parte de u-router como un complemento separado. Los cargadores se pueden definir en un archivo separado e importarse en varios componentes.
Muchas gracias, Eduardo. Eso fue extremadamente interesante. Y me encanta el design de tus diapositivas. Son súper atractivas. Ok. Así que, veamos las preguntas. Pero antes de la primera de todos, ¿se pueden usar rutas de tipo sin enrutamiento basado en archivos?
Entonces, se pueden usar las rutas de tipo sin enrutamiento basado en archivos, pero la idea es que estás separando la generación de los tipos y la escritura de las rutas, por lo que tienes que hacer algo de trabajo manual, mientras que el objetivo principal de este enfoque es que los tipos sean automáticos y no tengas que preocuparte por ello, por lo que es menos probable que cometas errores, es menos propenso a errores.
Ok, tiene mucho sentido.
Ok, veamos qué tenemos aquí, ¿este complemento admite Vue 2?
Vue 2? No, no hay soporte para Vue 2 porque los tipos en el enrutador son bastante diferentes, por lo que sería un gran, es principalmente una cuestión de tiempo, simplemente no tengo suficiente tiempo para hacer que admita Vue 2 en este momento.
Ok, tal vez en el futuro o? Incluso, dudo que pueda encontrar el tiempo para hacerlo en el futuro, pero invito a cualquiera a copiar el código y bifurcarlo para Vrouter 2, definitivamente.
Ok, lo has escuchado, una oportunidad de código abierto.
Luego, la siguiente pregunta, ¿cómo debemos manejar las rutas protegidas con enrutamiento basado en archivos?
Entonces, las rutas protegidas, por lo general, creas una guarda de navegación, por lo que aún crearías tu propia guarda de navegación, de la misma manera. Tienes la instancia del enrutador en algún lugar, por lo que simplemente router.beforeEach o router.beforeResolve. Hay otros patterns que puedes usar con Metafields, puedes definir Metafields en las rutas, lo que te permite tener guardas de navegación bastante precisas aplicadas a múltiples rutas. Por lo tanto, una sola guarda de navegación que se aplica en varias páginas.
Ok, genial. Creo que es un poco más difícil de explicar sin código.
Genial, tiene sentido.
La siguiente pregunta es, ¿hay alguna posibilidad de que la funcionalidad de desenchufar ViewRouter se integre en Sí, probablemente lo hagamos, pero para hacerlo primero tenemos que pasar por un RFC. La diferencia es que no es, quiero decir, la mayor parte del código no es runtime, ¿verdad? La mayor parte del código está construido. Por lo tanto, seguirá siendo algo que estará un poco aparte, por lo que si se convierte en parte de u-router, seguirá siendo como un complemento vid que se expone a través de una ruta diferente como u-router slash plugin o algo así.
Ok, genial.
La siguiente pregunta es, ¿se pueden definir cargadores en un archivo separado y luego importarlo en varios componentes?
Sí, solo necesitas exportar el cargador desde la página para indicarle al enrutador que esta página está utilizando ese cargador. Eso es todo. Y luego puedes usar el composable en cualquier lugar. Entonces, primero debes importar el cargador y luego exportar esa importación?
Sí, también puedes hacer solo export. No lo mencioné, pero tienes dos scripts, tienes el script regular y luego el script de configuración. Entonces, en el script regular, es donde puedes exportar cosas, y es donde puedes simplemente hacer export algo de algo más o puedes importarlo y luego exportarlo porque aún necesitarás importarlo en la configuración si no lo importas en el otro script. El editor facilita mucho obtener el comportamiento correcto porque simplemente autocompleta.
Ok, tiene mucho sentido.
Manejo de Archivos Index e ID
Short description:
El número de archivos index.vue e id.vue depende de las rutas y cómo se busquen. Si tienes rutas con la misma ruta común pero nombres diferentes, aún puedes encontrar los archivos fácilmente utilizando la estructura de carpetas. Es como los nodos en un árbol, donde las hojas pueden verse similares, pero los nodos no lo son.
Y la última pregunta es, ¿terminaremos con docenas de archivos index.vue e id.vue? ¿Cuándo? ¿O 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 otro nombre. Si tienes una página de usuarios y un usuario slash nuevo, tienes un usuario slash index y un usuario slash nuevo.vue. Entonces, cuando buscas los archivos, buscas users index, o probablemente uses mi espacio de usuario, lo siento. Cuando haces Control-P en tu VSCode, aún encontrarás tu camino 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 ven similares entre sí, pero los nodos no lo son. OK, perfecto. Muchas gracias, Eduardo. Y siéntete libre de hacer más preguntas en la parte de preguntas y respuestas de los oradores. Y sí, denos un poco de aplausos.
