Haciendo Magia: Construyendo un Marco de Trabajo Primero-TypeScript

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.