Haciendo Magia: Construyendo un Marco de Trabajo Primero-TypeScript

Rate this content
Bookmark

Voy a profundizar en los internos de Nuxt para describir cómo hemos construido un marco de trabajo primero-TypeScript que está profundamente integrado con el IDE del usuario y la configuración de comprobación de tipos para ofrecer seguridad de tipo de pila completa de extremo a extremo, sugerencias para diseños, middleware y más, opciones de configuración de tiempo de ejecución tipadas e incluso enrutamiento tipado. Además, destacaré lo que más me emociona hacer en los días venideros y cómo TypeScript hace eso posible no solo para nosotros sino para cualquier autor de bibliotecas.

31 min
21 Sep, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Daniel Rowe discute la construcción de un marco de trabajo primero-TypeScript en el Congreso TypeScript y comparte su participación en varios proyectos. Nuxt es un marco de trabajo progresivo construido sobre Vue.js, con el objetivo de reducir la fricción y la distracción para los desarrolladores. Aprovecha TypeScript para la inferencia y aspira a ser la fuente de verdad para los proyectos. Nuxt proporciona seguridad de tipo y extensibilidad a través de la integración con TypeScript. Migrar a TypeScript ofrece beneficios de mantenimiento a largo plazo y puede descubrir errores ocultos. Nuxt se centra en mejorar las herramientas existentes y encuentra inspiración en marcos de trabajo como TRPC.

1. Introducción y Antecedentes

Short description:

Daniel Rowe, mantenedor de NUXT y autor de bibliotecas de código abierto, discute la construcción de un marco de trabajo basado en TypeScript en el Congreso de TypeScript. Comparte su participación en varios proyectos, como Fontane, Magic Regular Expressions y Elk. Daniel invita a la audiencia a conectarse con él en su sitio web en roe.dev y ofrece asistencia con preguntas, ayuda y contribuciones de código abierto. También menciona su ubicación en el Reino Unido y el clima impredecible.

Cómo funciona TypeScript Hola. Es un verdadero placer estar aquí en el Congreso de TypeScript hablando sobre cómo hacer magia, construyendo un marco de trabajo basado en TypeScript. Mi nombre es Daniel Rowe. Soy autor de bibliotecas de open-source y mantenedor de NUXT, que es un marco para construir aplicaciones web. También estoy involucrado en algunas otras cosas desde Fontane, que ayuda a reducir el desplazamiento acumulativo del diseño con fuentes web personalizadas, hasta Magic Regular Expressions, que es una reimaginación de cómo podrían ser los proyectos, basado en gran medida en la magia de TypeScript, hasta Elk, que es un cliente para Mastodon, una red social distribuida. También soy un Google GDE y un Microsoft MVP. Puedes ponerte en contacto conmigo en mi sitio web en roe.dev. Si hay algo con lo que puedo ayudarte, me encantaría. Estoy accesible si tienes preguntas, o necesitas ayuda, o quieres contribuir al código abierto. Por cualquier motivo, sería realmente agradable decir hola. Vivo en el Reino Unido, en el noreste de Inglaterra, en un encantador entorno rural, a orillas de un río, a la sombra de un antiguo bosque. Tengo tres gatos y un perro, y este es el lugar donde estoy ahora. Y probablemente, cuando te pongas en contacto o me envíes un mensaje, me encontrarás en esta misma situación. Ha estado lloviendo un poco hoy, pero también hace sol. Así que eso es una buena indicación del clima del Reino Unido, si no estás familiarizado con él.

2. Integración del marco Nuxt y TypeScript

Short description:

Nuxt es un marco progresivo construido sobre Vue.js, que proporciona una experiencia de desarrollador fluida con las mejores prácticas y configurabilidad. El objetivo es reducir la fricción y la distracción, permitiendo a los desarrolladores centrarse en su código. El uso de TypeScript a nivel central tiene como objetivo mejorar esta experiencia, con un enfoque en ser la fuente de verdad, aprovechando la inferencia, permitiendo la ampliación y revelando la verdad del proyecto al usuario final.

Y probablemente te estés preguntando qué es Nuxt, si no te has encontrado con él antes. Es un marco progresivo construido sobre Vue.js. Vue es la capa de renderizado para el front end, pero es full stack. Por lo tanto, también tiene un motor de servidor llamado Nitro, que ahora es un marco por sí mismo y también es utilizado por otros meta-frameworks.

Una de las cosas clave para Nuxt es la developer experience. Por lo tanto, se trata de hacer algo que sea fácil de usar, que tenga las best practices incorporadas, pero que no imponga una alta barrera de entrada, pero al mismo tiempo sea configurable y te permita extenderlo según lo necesites, a medida que creces y tienes diferentes requisitos, debería crecer contigo.

Hace unos años, empezamos a reconstruir Nuxt. Y una de las cosas en las que trabajamos que queríamos hacer era pensar en cómo podríamos hacer Nuxt aún más mágico. Y creo que la magia es una característica realmente importante de un marco que me gustaría usar. Sé que a veces puede usarse en un sentido peyorativo, pero creo que la magia es algo que queremos en términos de developer experience. Y para mí, son realmente estas dos cualidades. Se trata de reducir la fricción, manteniéndote en un solo contexto, y de reducir la distracción. Por lo tanto, adoptando un principio más minimalista.

Entonces, dondequiera que cambies de contexto, si eres un desarrollador y estás escribiendo código, las ideas fluyen a través de ti y hacia afuera, si hay algo que te detiene de eso, ya sea que tengas que ir a la documentation para averiguar algo, o necesites revisar en otra parte de tu proyecto para entender si puedes hacer lo que estás intentando hacer, eso va a ralentizarte y crear una sensación de frustración. Y lo mismo es cierto, creo, con la distracción. Entonces, cuando te encuentras teniendo que mantener una configuración de bundler compleja o repetir el código una y otra vez, incluso cuando abres un nuevo componente y ves 20 líneas de importaciones en la parte superior antes de que incluso veas el código que quieres ver, todo eso, creo, puede interponerse en el camino del estado de flujo, algo que te hace sentir productivo y disfrutar y prosperar en lo que estás haciendo. Y por lo tanto, creo que la magia es una de las cosas que podemos hacer, puede proporcionarnos ofertas de marcos que pueden mejorar dramáticamente la experiencia de los desarrolladores.

Entonces, cuando llegamos, como decía, a reconstruir Nuxt desde cero, para nosotros, se trataba de pensar, ¿cómo podemos usar TypeScript para hacer este tipo de magia? Porque construir el marco, escribirlo en TypeScript es prácticamente una apuesta segura. Pero, ¿qué podríamos hacer si apuntáramos a tener TypeScript incorporado a un nivel mucho más central para que el marco en sí sea nativo de TypeScript? Y se me ocurrieron estas cuatro posibilidades diferentes, y podrías tener otras, y más podrían irme más tarde. Pero pensé que estas serían una guía útil para seguir. Y la primera es que tiene que ser diseñado para ser la fuente de verdad en un proyecto. El marco necesita ser diseñado para la inferencia, por lo que aprovecha al máximo TypeScript para hacer lo que puede hacer. Necesita ser diseñado para la ampliación. Y necesita ser diseñado para revelar toda la verdad del proyecto tanto como sea posible al usuario final. Entonces, ¿qué quiero decir? Primero, diseñado como una fuente de verdad. Entonces, en el momento en que clonas un nuevo proyecto en cualquier marco, a menudo encontrarás que hay una página en la documentation llamada usando con TypeScript. Y en esta página, entonces hay una tsConfig. Y puedes ir a la página y copiar y pegarla en tu proyecto. O tal vez tienes una plantilla donde ya está. Y desde ese momento, tu configuración de TypeScript comienza a divergir de la realidad de la biblioteca.

3. Fuente de Verdad e Integración de TypeScript

Short description:

Es importante establecer una única fuente de verdad para un proyecto. Nuxt adopta un enfoque diferente al ser la fuente de verdad y generar una tsConfig que refleja esa verdad. Permite la personalización de alias en la configuración de Nuxt y proporciona la configuración de ruta correcta. Nuxt también se beneficia de la iniciativa de Vue llamada Vola, que es una integración de editor cruzado de marcos e IDE para TypeScript. Envuelve a TypeScript y se puede ejecutar desde la línea de comandos, lo que lo hace versátil y no ligado a un editor específico. Nuxt aprovecha el poder de TypeScript para la inferencia y tiene como objetivo conectar TypeScript y el código del usuario.

Podrías cambiar un poco aquí, cambiar un poco allá. O tal vez la biblioteca agrega una nueva característica. Y creo que es realmente importante pensar, ¿cuál es la fuente de verdad para el proyecto? Entonces, por ejemplo, es posible configurar rutas en tus alias de tsConfig efectivamente. Y es realmente importante que coincidan con los valores reales que tu bundler entiende.

Y hay diferentes enfoques para este tipo de cosas, asegurando que haya una única fuente de verdad. Y así algunos frameworks, Avit, por ejemplo, leerán tu configuración de TypeScript e intentarán respetar lo que está allí. Pero hemos adoptado un enfoque diferente con Nuxt. Nuestro objetivo es que Nuxt sea la fuente de verdad. Y generamos una tsConfig que refleja esa verdad. Así que puedes personalizar los alias en tu configuración de Nuxt, eso es importante porque necesitamos saber sobre ellos. También significa que podemos exponerlos a las integraciones de módulos. Y luego generamos una tsConfig que tiene la configuración de ruta correcta. Porque entendemos las condiciones de exportación de sub-rutas, podemos configurar el bundler, la resolución de módulos para bundler. Porque admitimos la importación de archivos JSON, podemos decir que eso también está permitido. Y por lo tanto, creo que tiene sentido que nosotros estemos a cargo de eso.

También creo, y esto no es algo que hicimos como NUX, más bien algo de lo que nos beneficiamos, pero hubo una iniciativa de Vue que comenzó Johnson llamada Vola. Y es una fantástica integración de editor para VS Code, al menos así es como comenzó, permitiendo que TypeScript entienda el archivo único de Vue, componentes de archivo único, que parecen un poco más a código, y archivo único de Vue, componentes de archivo único, que parecen un poco más a HTML que a TypeScript. Pero básicamente los envuelve y los transforma y hace que TypeScript entienda esto. Pero Vola fue construido de tal manera, ahora es multiplataforma, por lo que no es solo Vue, y también es multi-IDE, por lo que no es solo VS Code. Y está construido de tal manera que envuelve a TypeScript, por lo que incluso puedes ejecutarlo desde la línea de comandos, lo que significa que todo lo que hemos hecho, hemos tratado de hacerlo de tal manera que no sea específico para un solo editor, por lo que no es específico de VS Code, es específico de TypeScript. Lo que significa que somos capaces, por ejemplo, ahora JetBrains usa Vola. Pero incluso si no lo hicieran, sería posible solo usando Vue TSC en la línea de comandos para obtener soporte completo de tipos para cada característica que construimos. Y creo que ese es un enfoque mejor en general, que crear, por ejemplo, un plugin que hace algo mágico específicamente en un IDE. Así que siempre que sea posible, hemos intentado usar cosas como funciones definidas que proporcionan tipos en lugar de depender de un plugin mágico que solo da pistas en tu editor. Pero no se trata solo de establecer la fuente de verdad, eso es prácticamente el comienzo. Hemos intentado tanto como sea posible usar el poder de TypeScript para las cosas en las que es bueno, como la inferencia. Así que en lugar de escribir muchos y muchos archivos en el disco con mucha información, tanto como sea posible, solo queremos conectar TypeScript y el código del usuario. Así que aquí hay dos ejemplos. Primero, seguridad de tipo de extremo a extremo. Así que en NUX 2, teníamos la capacidad de tener puntos finales de servidor con un patrón de estilo de conexión express de nodo.

4. Seguridad de Tipo e Integración

Short description:

En Nuxt 3, los desarrolladores tienen control total sobre el punto final del servidor y la función de búsqueda, lo que permite proporcionar tipos. La firma se ha modificado para devolver directamente el valor JSON, con soporte para otros tipos de datos. Este enfoque facilita la inferencia y permite sugerencias de tipo, proporcionando seguridad de tipo sin la necesidad de crear un cliente adicional o funciones de envoltura. Es una integración perfecta con TypeScript y el punto final, ofreciendo seguridad de tipo con una búsqueda web estándar.

Entonces podrías acceder a los objetos de solicitud y respuesta del nodo. Podrías llamar a funciones como reenviar, podrías pasar una cadena, y eso se va a enviar de vuelta al final, al usuario que lo está consumiendo. Pero por supuesto, no tienen type safety para eso. ¿Cómo podrían tenerlo? A menos que crees un cliente personalizado, tal vez estés usando algo como TRPC, no habría forma de tipificar esto.

Y pensamos para NUX 3, en realidad tenemos control total de esto. Tenemos control del punto final del servidor, está en tu proyecto. También tenemos control de la función de búsqueda que va a buscar desde él, por lo que realmente podemos proporcionar tipos. Así que hicimos esto. Cambiamos la firma a una que no solo llama a un método, como reenviar, a una que realmente devuelve directamente el valor que... El valor JSON que devuelve. También admitimos otras cosas como devolver un flujo o un búfer o cosas así, o nulo para devolver una respuesta 2 o 4. Y hay muchas otras características y razones por las que lo construimos de esta manera. Pero una de ellas es que realmente permite una inferencia muy agradable. Así que simplemente podemos decir, por ejemplo, a TypeScript, esta clave, como esta ruta, API test, corresponde a este archivo y su tipo de retorno. Eso es todo lo que necesitamos hacer. Luego proporcionamos una búsqueda envolvente, que es agradable de otras maneras. Así que pasa automáticamente JSON, por ejemplo. Pero también puede proporcionar tipos. Y así podemos sugerir los posibles rutas en tu aplicación, y puedes seleccionarlo. Y también podemos proporcionarte los tipos reales de esos como la respuesta. No porque hayamos hecho un trabajo duro en nuestro extremo para generar esos tipos, sino simplemente porque hemos conectado TypeScript y el punto final. Ni siquiera tienes que hacer ningún trabajo como usuario, no tienes que crear un cliente o un envoltorio o llamar a alguna función especial. Es solo una búsqueda web estándar normal. Y obtienes type safety para ello.

5. Patrón de Inyección y Extensibilidad en Nuxt

Short description:

En Nuxt2, había un patrón de inyección común para agregar singletons globales. Sin embargo, cuando se involucran tipos, el acceso seguro a los tipos se vuelve importante. Nuxt aprovecha la inferencia y una función de definición para proporcionar acceso seguro a las inyecciones. A medida que los usuarios crean más plugins, simplemente pueden ser añadidos a una lista. La filosofía de Nuxt es ser extensible, con cientos de módulos mantenidos por la comunidad disponibles. Los autores de módulos pueden personalizar y controlar los tipos y el entorno de tipos añadiendo sus propias plantillas a la construcción de Nuxt.

Otro ejemplo, en Nuxt2, teníamos un patrón de inyección común, donde podrías hacer algo como añadir un singleton global en tu aplicación. Así, tal vez un ayudante de autenticación. Y teníamos este patrón donde podías inyectar, podrías llamar a una función de inyección y pasar algo que luego se inyecta en tu aplicación. Y luego podrías usarlo. Pero, por supuesto, en el momento en que los tipos entran en juego, no va a funcionar porque lo que idealmente quieres hacer es tener acceso seguro a este ayudante. Y depende de ti como usuario crear los tipos para eso y crear una ampliación. Y en realidad, como framework, no queremos que los usuarios tengan que escribir tipos. No queremos que tengan que escribir ampliaciones. Así que, pudimos usar, de nuevo, la inferencia, el mismo tipo de patrón donde tenemos una función de definición y un tipo de retorno. Y hacer esto, ya sea teniendo una función o un objeto con funciones dentro de él, este patrón de inferencia funciona realmente bien. Porque todo lo que necesitamos hacer, de nuevo, es un poco más complejo que la API, pero sólo tenemos que apuntar el archivo a algunos tipos que hacen un masajeo de los data. Y eso es todo lo que necesitamos hacer. Entonces tienes acceso seguro a todas tus inyecciones. Y así, a medida que el usuario crea más plugins, lo único que tenemos que hacer es añadirlos a una lista en lugar de hacer cualquier tipo de transformación o algo así. Así que aprovechamos la inferencia donde podemos para hacer el mejor uso del poder de TypeScript. Pero también design específicamente para la ampliación. Y como dije antes, esto es realmente fundamental para la filosofía de Nuxt. Queremos ser extensibles. Es una de las cosas que nos hace, creo, únicos. Es la community y el ecosystem que han surgido a su alrededor. Pero realmente ha significado que tenemos que construir Nuxt de una manera que pueda ser extendida. Así que tenemos módulos de Nuxt, que son integraciones. Tenemos cientos y cientos de ellos. Algunos creados son módulos centrales, pero la mayoría son mantenidos por la community, algunos privados dentro de agencias y empresas que usan Nuxt. Y son todo, desde integraciones con CMSs hasta authentication hasta la obtención de data hasta el caching hasta módulos muy personalizados y específicos. Puedes ver algunos de ellos en nuxt.com forward slash modules. Y los usuarios pueden hacer lo mismo. Entonces, ¿cómo se ve para permitir a los usuarios y autores de módulos personalizar y controlar los tipos y el entorno de tipos de un proyecto? Así que tenemos un par de cosas que hemos hecho disponibles. Así que es posible para los autores de módulos añadir sus propias plantillas en la construcción de Nuxt. Y también les permitimos añadir plantillas de tipos específicamente para ampliar algunos de los tipos que Nuxt proporciona, o incluso los suyos propios.

6. Configuración de Tipo y Experiencia de Desarrollo

Short description:

Las opciones del módulo pueden ser definidas y modificadas en tiempo de ejecución, proporcionando flexibilidad para los desarrolladores. Nuxt simplifica la configuración de tipo y permite una amplia personalización. Las referencias de configuración TS generadas por Nuxt proporcionan alias y patrones de inclusión/exclusión, permitiendo la seguridad de tipo para los componentos de manera predeterminada. Los desarrolladores pueden crear sus propios componentes con acceso seguro a las propiedades. Los errores de tipo son capturados, proporcionando una experiencia de desarrollo sin problemas.

Son completamente asíncronos, pueden ser definidos en runtime y modificados en runtime, dependiendo de lo que el usuario esté haciendo. Así que si estás en desarrollo construyendo algo y creas un archivo o cambias las opciones del módulo, podría cambiar lo que el módulo decide hacer, esta plantilla de tipo en particular sería automáticamente registrada en el contexto de la aplicación. Así que escribiría este archivo en el disco y luego lo añadiría a las referencias de ts-config. Y definiría que hay otro campo en tus metadatos raíz que puedes establecer en el ayudante de definición de metadatos de página y puedes acceder en use root.meta si estás interesado.

Pero el punto es que es simple para los autores de módulos hacerlo. Y de hecho, todo lo demás sobre la configuración de tipo también es accesible. Así que ya sea los detalles específicos de la ts-config que generamos o las referencias y declaraciones que realmente inyectamos a través de un archivo nuxt.d.ts personalizado, todo está disponible, lo que significa que casi no hay personalización de tipo que sea imposible de hacer desde el punto de vista de un módulo. Así que esperamos que eso proporcione suficiente infraestructura para la extensibilidad en el frente de tipo. Pero luego está realmente la parte más importante, que es que luego necesitamos exponer la realidad, como la realidad fundamental de lo que es Nuxt y cómo funciona el bundler al usuario en su IDE, desarrollando eso, y por supuesto, en la etapa de comprobación de tipo también, eso va sin decir.

Así que pensé en hacer una pequeña demostración de cómo podría ser eso. Así que esta es una aplicación Nuxt que he iniciado, es muy básica. Estoy ejecutando un servidor de desarrollo en segundo plano, creo. Y verás, por supuesto, que tenemos esta TS config. Este es solo un proyecto clonado reciente. Y esta TS config en realidad hace referencia a otra TS config, esta es generada por Nuxt aquí. Y tiene mucha información, así que estos son los alias que están disponibles. Y generamos algunos patrones de inclusión y exclusión patterns también. Y entonces en tu aplicación, eso significa que realmente no necesitas configurar nada. Así que de manera predeterminada, obtienes algo como, obtienes seguridad de tipo para los componentes que están disponibles para ser importados automáticamente. Y así, en este caso, Nuxt.welcome es un componente, obtienes acceso seguro a sus propiedades. Si creas tu propio componente, tendrías exactamente lo mismo allí también. Así que si creara un MyComponent.view y le diera, digamos, algunas propiedades, usaría la sintaxis de vista para definir las propiedades a nivel de tipo, haría algo como customPropString. Y luego podría seguir adelante y usar esto en mi aplicación. Así que voy a poder acceder a MyComponent directamente. Existe. Me va a lanzar un error de tipo porque en realidad necesita tener customProp proporcionado, y eso en realidad tiene que ser una cadena. Así que en realidad tengo que darle un valor. Y así tengo type safety. Puedo hacer clic para ir al componente. También tengo otros tipos de cosas.

7. Seguridad de Tipo y Variables de Entorno

Short description:

Al crear un punto final del servidor, puedo acceder a la lista de rutas y los datos que se devuelven. La seguridad de tipo puede ser impuesta especificando los métodos permitidos. Crear diseños personalizados y usar middleware proporciona acceso seguro a las rutas. Nuxt consume variables de entorno a través de RuntimeConfig, permitiendo cambios específicos en tiempo de ejecución. El uso de RuntimeConfig proporciona acceso seguro a las variables de entorno sin validación adicional.

Vaya, estoy jugando como TS. Que en realidad puedo acceder en el script. Entonces, por ejemplo, si fuera a crear un punto final del servidor, como el que acabo de demostrar, entonces sería capaz de hacer algo como esto. Poo bar, y eso es entonces accesible directamente aquí. Obtendré acceso seguro al listado de rutas en mi aplicación, y obtendré acceso a los data que se devuelven. Y en este caso, podrías acceder a ese punto final con un método post también. No he especificado. Pero si lo restringiera, digamos algo como esto solo puede ser accedido por un método get, entonces en realidad TypeScript también me lanzará un error aquí y dirá que tiene que ser un método get. Así que hay muchas formas en las que podemos traer type safety de esta manera en la aplicación.

Si fuera a hacer algo como crear una carpeta de diseños y crear un diseño personalizado, algo como esto. Y también podría hacer algo. Tenemos un concepto de middleware que controla si puedes o no acceder a una ruta en particular o si podrías ser redirigido a otro lugar en su lugar. Ambos son seguros desde el punto de vista del usuario. Así que si habilitara el enrutamiento en la aplicación, que se hace simplemente creando un directorio de páginas, y luego quisiera usar el diseño y el middleware en mi página, en realidad en este punto tendría acceso seguro. Así que sabría que el diseño tiene que ser realmente personalizado es la única opción allí para mí. Y si quiero elegir un middleware, bueno, de nuevo, tengo acceso seguro. Tiene que ser middleware de autenticación, que de nuevo es algo realmente útil porque significa que si luego voy y renombro una de esas cosas, voy a obtener una advertencia cuando yo o un error cuando intento construir la aplicación.

Hay más. Así que desde una perspectiva de Nuxt, la forma en que consumimos las variables de entorno es a través de algo llamado RuntimeConfig. No queremos pasar todo en runtime, queremos ser muy específicos sobre lo que continúa siendo cambiable en runtime. Así que en este caso, he establecido un token de GitHub. Eso va a ser accesible... Bueno, para empezar, somos capaces de generar una pequeña pista, que dice que esto es en realidad sobrescribible con esta variable de entorno. Así que si creas un archivo .env sin valor, entonces eso va a definir lo que va a ser en runtime. Así que eso es algo útil tal vez para DX para los usuarios. Si luego voy y trato de usar eso en la aplicación, algo como usar RuntimeConfig, entonces en realidad obtengo acceso seguro al hecho de que tengo GitHub y Token, que de nuevo es algo bastante útil de tener. Y en efecto significa que obtengo acceso seguro a mi entorno sin necesidad de añadir ninguna validation adicional. Next lo hace por mí. También tenemos otras cosas como tenemos una configuración de aplicación, por ejemplo, esto se utiliza para cosas como reactivas pero configuración en tiempo de construcción. Así que podría decir algo como, voy a pegar un tema.

8. Configuración de la App y ts.config

Short description:

Existen diferentes fuentes para la configuración de la app, incluyendo módulos y capas de tema. Se utiliza un ts.config separado para la carpeta del servidor para proporcionar un conjunto diferente de auto importaciones. Esto mejora la experiencia del desarrollador al especificar qué se puede utilizar dónde. Para más información, visita nuxt.com o conecta con Nuxt en Twitter, x, o Mastodon.

Y en realidad hay muchas fuentes diferentes para la configuración de la app. Podrías tener un módulo, que añade algo, o podrías haber creado una capa de tema. Y trataré de replicar eso haciendo algo en un archivo de configuración de la app y también en este archivo de configuración de la app. Usamos solo un tipo básico para fusionar eso y en realidad deduplicar y eliminar valores indefinidos basados en las diferentes configuraciones de la app que se proporcionan.

Y también tendrías acceso a algo como eso donde realmente podrías acceder al tema. Y tal vez aún no lo he guardado. Y tendrías el mismo acceso en tu configuración de NextJS también. Así que el foo.bar podría pasar también. ¿Dónde está esto? Así que debería poder tener acceso a eso también.

Hay mucho más, mucho más que podríamos tener. Pero una cosa que quiero destacar porque es un patrón interesante y todavía estamos trabajando en esto. Pero tenemos un ts.config separado para nuestra carpeta de servidor porque en realidad es un entorno separado. Así que algunas cosas son parte de la vista de tu aplicación. Esa es la mayor parte de tu app Nuxt. Esa es la parte del front end. Así que tenemos cosas como refs. Así que este es un valor reactivo, y va a ser rastreado. Es reactivado, va a ser rastreado, va a desencadenar rerenders. Pero en realidad, no hacemos esta auto importación disponible en las rutas del servidor porque las rutas del servidor no están realmente ejecutándose en un contexto de vista. Así que al tener este ts.config adicional, somos capaces de decirle al IDE que este directorio tiene un conjunto diferente de cosas, un conjunto diferente de auto importaciones. Así que en realidad podemos darle al usuario una mejor developer experience porque saben qué cosas se pueden usar dónde. Y creo que hay muchas más cosas como esa, que podemos desempaquetar y hacer disponibles a medida que pasa el tiempo.

Bueno, hay mucho más que me encantaría mostrarte. Pero me temo que realmente no tengo tiempo ahora, y todavía quedan muchas buenas charlas por venir. Pero si estás interesado en algo de lo que te he mostrado, echa un vistazo a nuxt.com. Hay algo de documentation allí y una guía para empezar. Puedes seguir a Nuxt en Twitter o x, como creo que está empezando a ser llamado, o Mastodon. Y tenemos un servidor de Discord que es bastante, bastante activo, y definitivamente lo veré si haces una pregunta allí. Pero ponte en contacto conmigo si tienes alguna pregunta o hay algo que pueda hacer para ayudarte a empezar con Nuxt o si tienes una idea o una sugerencia para mejorar las cosas, también me encantaría escuchar de ti. Eso es prácticamente todo por mi parte, pero ha sido un verdadero placer estar aquí hablando contigo.

9. Beneficios de Migrar a TypeScript

Short description:

El mayor beneficio de migrar una base de código legado a TypeScript es el mantenimiento a largo plazo. Al lidiar con una base de código legado, el mantenimiento se convierte en el enfoque principal. La migración también puede descubrir errores ocultos que han estado al acecho bajo la superficie. La rigurosidad de TypeScript puede ser más implacable que JavaScript al exponer estos problemas.

Y espero que hayas disfrutado de la conferencia tanto como yo hasta ahora. Todo lo mejor. ¿Cuál crees que es el mayor beneficio de migrar una base de código legado a TypeScript? ¿Qué piensas, Daniel? ¿Estás de acuerdo con estos? Tenemos el mantenimiento a largo plazo en primer lugar, luego reducir los errores, luego facilitar la adición de nuevas características. El 0% de las personas eligió no obtener ningún beneficio en absoluto. ¿Suena correcto? Bueno, creo que absolutamente la palabra clave allí es legado. Así que en el momento en que estás hablando de una base de código legado, parece que probablemente el mantenimiento va a ser tu principal beneficio. Parece que podría no estar en desarrollo activo. Pero no me sorprendería en absoluto si al migrar, terminas descubriendo muchos errores que han estado allí bajo la superficie. Quiero decir, esa es mi experiencia. Sí, definitivamente. TypeScript tiende a ser un poco más cruel que JavaScript en esos puntos.

QnA

Autocompletado e IntelliSense en Nuxt

Short description:

¿Cómo funcionan el autocompletado y IntelliSense en Nuxt para las API externas? Puedes proporcionar tu propio tipo o cliente de API. La API interna utiliza una interfaz que puede ser extendida. También puedes proporcionar tu propio tipo o extender la interfaz. Nuxt no planea pasar a JSDoc, pero el orador aprecia la motivación detrás de ello.

Así que pasemos a las preguntas que la gente tiene para ti. Tengo una buena para empezar. ¿Cómo funciona el autocompletado y IntelliSense en Nuxt para las API que no están escritas dentro de Nuxt? Así que cuando estás hablando con una API externa, ¿cómo funciona eso? Así que puedes proporcionar tu propio tipo para eso si quieres. O tu propio cliente de API si lo necesitas. Así que la forma en que funciona la API interna es que tenemos la ruta, como la barra inclinada hacia adelante / API test es una clave de una interfaz. Y esa interfaz puede ser extendida. Podrías extenderla tú mismo con otras claves. Podrías extenderla, por ejemplo, para URLs enteras. Aunque eso no es necesariamente algo que documentamos. Y también puedes proporcionar tu propio tipo. Proporciona tu propio tipo y envuelve la búsqueda interna con tu propio tipo. O simplemente podrías extender la interfaz y tipificar el resultado. Sí. Vale, eso tiene sentido. Así que lo haces como un declare global, tienes la interfaz dentro y le añades cosas. Sí, sencillo y simple. Sería extender. Es en realidad una exportación de interfaz de NitroPack. Así que simplemente haces declare NitroPack y luego interfaz API interna, y luego pondrías la clave. Super suave. Sí, está bien. Es una idea interesante hacerlo con una interfaz global, eso podría haber sido una mejor idea. Quiero decir, estoy seguro de que encontraste la solución correcta, definitivamente.

Pasemos a la siguiente. Bueno, esta es la pregunta más popular. Mucha gente está interesada en tus pensamientos sobre el reciente movimiento, por ejemplo, Svelte eligiendo JS sobre TypeScript para las frameworks porque tiene una mejor experiencia de depuración. Y para aquellos, esto es elegir JSDoc sobre TypeScript en lugar de elegir simplemente JavaScript sobre TypeScript. Me pregunto si eso es algo en lo que has pensado para Nuxt? Así que, sinceramente, no es algo que esté considerando para Nuxt pasar a JSDoc. Pero diré que me encanta esa motivación. Así que, Ir-a-definición ha sido algo de lo que he aprendido una gran cantidad, para mirar realmente el código fuente.

Problemas de Herramientas e Inspiración

Short description:

Cuando se trata de problemas de herramientas, es mejor centrarse en mejorar las herramientas existentes en lugar de cambiar el lenguaje. Prefiero ver los archivos fuente, especialmente cuando trabajo con código de marco. En términos de inspiración, no estaba al tanto de muchos otros marcos que hicieran seguridad de tipo de extremo a extremo cuando comenzamos. Sin embargo, TRPC fue un gran descubrimiento que se alineó con nuestros objetivos. La clave es minimizar la generación de código y dejar que TypeScript maneje la mayor parte del trabajo. No hay desventajas en este enfoque, siempre y cuando evitemos involucrarnos demasiado en la generación de código.

Creo que eso es un problema de tooling, más que algo que debería llevarme a cambiar el lenguaje en el que estoy escribiendo el código subyacente. Entonces, creo, quiero decir, hay otras soluciones allí. Por ejemplo, es relativamente fácil en VS code simplemente ir a la parte superior y seleccionar el archivo fuente en lugar del archivo de declaración si quieres ver el origen. Y creo que eso también es algo que va a mejorar con futuras versiones de VS code. Como, puedes establecer una opción para decidir a dónde quieres ir. Aunque, quiero decir, es motivador, supongo. Preferiría ver los archivos fuente. Sí, especialmente cuando estás trabajando en código de marco, también.

Otra pregunta aquí de alguien llamado Matt, que para ser completamente transparente soy yo, ¿qué otros frameworks y bibliotecas fueron una inspiration cuando estabas pensando en la seguridad de tipo de extremo a extremo para Nuxt? ¿Qué piensas, oh, ese marco lo está haciendo muy bien. Necesitamos copiarlo o tomar inspiration de él. ¿Cuáles fueron las cosas de las que te inspiraste? En toda honestidad, no estaba al tanto de muchos otros frameworks que estaban haciendo esto cuando empezamos a hacerlo. Así que alrededor del tiempo que empecé a tuitear sobre la búsqueda tipada inicial, TRPC Alex se acercó y dijo, hey, estoy haciendo algo, ¿has oído hablar de TRPC? Y nunca había oído hablar de él y empecé a investigarlo, fue increíble, supongo que una especie de evolución convergente que estamos yendo hacia lo mismo. Y no creo que me esté olvidando de nadie, pero creo que muchos de nosotros en el ecosystem, todos estamos buscando lo mismo al mismo tiempo. Que es, sabes, TypeScript es increíble, ¿cómo podemos hacerlo automático y cómo podemos obtener esa seguridad de tipo de extremo a extremo.

Aquí hay una interesante también. Una muy buena pregunta aquí. Haremos esta última pregunta. Nux se basa en la generación de código que permite la inferencia de tipo automática. ¿Has notado alguna desventaja en ese enfoque en comparación con, digamos, un enfoque TRPC que es menos generador de código? Entonces, lo principal que creo que repito lo que dije, que la generación de código debería ser lo más pequeña posible. Entonces, simplemente apuntando a TypeScript a que esta es la clave y la exportación por defecto del archivo es el resultado que coincide con ella. Así, TypeScript está haciendo realmente lo máximo posible y la generación de código no es la bisagra como no es lo principal. De hecho, significa que sería posible hacerlo tú mismo incluso. No es mucho código el que se genera. Creo que eso es lo mejor. No creo que haya ninguna desventaja en eso. Las desventajas serían si te involucras mucho en la generación de código, de la cual quiero mantenerme alejado. Como una especie de enfoque de generación de código GraphQL o algo así. Bueno, Daniel, muchas gracias por esas preguntas. Gracias por una charla increíble. Todos, aplaudan a Daniel y pueden ir a conocer a Daniel en la sala de conferenciantes en Spatial.Chat también. Gracias, Daniel.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.