TypeScript para Autores de Bibliotecas: Aprovechando el Poder de TypeScript para DX

Rate this content
Bookmark

Usando ejemplos de código abierto de la vida real, exploraremos el poder de TypeScript para mejorar la experiencia de tus usuarios. Cubriremos las mejores prácticas para los autores de bibliotecas, así como consejos y trucos para llevar una biblioteca al siguiente nivel. Esta charla cubrirá:


- cómo aprovechar la inferencia de tipos para brindar ayuda a tus usuarios;

- usar tipos para reducir la necesidad y complejidad de tu documentación, por ejemplo, usando sobrecargas de funciones, tipos literales de cadena y funciones auxiliares (no-op);

- configurar pruebas para asegurarte de que tu biblioteca funcione (¡y tus tipos también!) con herramientas como tsd y expect-type;

- tratar los tipos como una API y reducir los cambios que rompen la compatibilidad al enviar mejoras;

- me basaré en mi experiencia con bibliotecas como nuxt3, sanity-typed-queries y typed-vuex y mostraré lo que logramos hacer y lo que haría diferente en el futuro.

25 min
29 Apr, 2022

Video Summary and Transcription

TypeScript para autores de bibliotecas ofrece beneficios tanto para uso interno como externo, mejorando la calidad del código y proporcionando una comprensión precisa de las bibliotecas. La documentación y los ejemplos deben estar en código para proporcionar información actualizada. Las pruebas de tipos junto con las pruebas unitarias garantizan una tipificación precisa. La gestión de cambios y la exposición de tipos requiere una versión cuidadosa. La integración profunda de tipos mejora la usabilidad. El uso de un mapa en TypeScript permite una implementación y personalización más sencillas. Aprovechar los tipos en las bibliotecas puede generar código basado en el acceso del usuario. La integración de TypeScript con Nuxt proporciona soporte y declaraciones de tipos.

Available in English

1. Introducción a TypeScript para autores de bibliotecas

Short description:

TypeScript para autores de bibliotecas ofrece beneficios tanto para uso interno como externo. Internamente, ayuda a mejorar la calidad del código, cubrir casos límite y facilitar la refactorización. Externamente, proporciona a los usuarios una comprensión precisa de cómo funcionan las bibliotecas, ofreciendo una representación realista de su funcionalidad. TypeScript permite a los usuarios obtener información sobre las bibliotecas y comprender el comportamiento esperado de las llamadas a funciones.

Hola. Es un placer estar aquí hoy, hablando sobre TypeScript para autores de bibliotecas. Es algo que me interesa mucho porque soy egoísta y me encanta usar bibliotecas con una gran experiencia de desarrollo, y estoy seguro de que ustedes también. Mi nombre es Daniel Rowe. Estoy ubicado en el noreste del Reino Unido, y soy parte del equipo principal de Nuxt, y también mantengo algunos otros paquetes de código abierto. Debo decir de antemano, esta es mi perspectiva a medida que nos adentramos en TypeScript para autores de bibliotecas, es posible que tengan otras ideas. Es posible que tengan enfoques mejores, y me encantaría saber de ustedes si ese es el caso. Por favor, contáctenme, ya sea por correo electrónico o Twitter es una excelente manera de ponerse en contacto. Por favor. Me encantaría conectarme más tarde.

Entonces, para empezar, la pregunta que me gustaría plantear es ¿cuál es el punto de TypeScript para autores de bibliotecas, supongo? Y obviamente, incluso si no estuvieran exponiendo sus tipos fuera de su propio proyecto, creo que aún habría beneficios. Ciertamente, yo encontraría eso por mí mismo. Creo que TypeScript ayuda a mejorar el código que producimos. Nos ayuda a cubrir casos límite. Nos ayuda a ver las posibles alternativas y resultados de lo que estamos creando. Y nos ayuda con cosas como la refactorización, asegurándonos de que no hayamos dejado algo fuera. Muchos beneficios enormes para usar TypeScript internamente. Pero creo que al mirar la pregunta de por qué usamos TypeScript para beneficio externo, la razón clave es la verdad. Y creo que hay un par de implicaciones diferentes para esto que espero explicar hoy. Pero creo que todo se reduce a la verdad. Estamos permitiendo a nuestros usuarios una ventana hacia cómo funcionan nuestras bibliotecas. Esa ventana es precisa. Debe ser precisa. Les estamos ofreciendo una alternativa a mirar nuestro código fuente o leer nuestra documentación. Algo que es en realidad una representación realista de lo que está sucediendo. Y eso, creo, es una de las cosas que hace que TypeScript sea tan increíble, cuando lo usas al consumir alguna otra biblioteca. Porque estás obteniendo información a través de él. El popup de tu IDE te está diciendo algo sobre cómo funciona en el fondo. Te está diciendo algo sobre lo que puedes esperar que regrese de eso

2. Documentación y Ejemplos en Código

Short description:

Los tipos son parte de tu documentación. La documentación de la API y los ejemplos deben estar en tu código. Los usuarios obtienen información actualizada al usar tu biblioteca. No es necesario tener un sitio web separado. Puedes agregar enlaces, ejemplos, valores predeterminados e información de versión. Estándares maduros como jsdoc proporcionan una excelente manera de ver la documentación en tu IDE. Incluso puedes alojarlo usando herramientas como jsdocs.io o unpiped.

llamada a función. Las opciones posibles que puedes pasarle. Ese tipo de cosas. Todo se trata de la verdad para mí. Y la primera implicación es la documentación. Eso también se trata de la verdad, ¿no es así? Entonces, los tipos son parte de tu documentación o tal vez incluso de tu documentación. Ciertamente, los tipos y TS doc, JS doc, usaré los términos indistintamente aunque no sean exactamente iguales. Pero pueden proporcionar la documentación de tu biblioteca. Entonces, si piensas en agregar comentarios inmediatamente antes de cada función, cada interfaz, cada constante que expones de tu biblioteca, puedes describirlo con precisión allí. Mi opinión para hoy es que toda tu API documentación y ejemplos deben estar en tu código. Esto significa que cuando tus usuarios realmente usan tu biblioteca, obtienen información actualizada y precisa sobre la versión que están consumiendo en ese momento. No necesitas tener un sitio web elegante con un menú desplegable que permita a los usuarios seleccionar las versiones principales, si tu documentación está en el propio código. Su editor mostrará la versión correcta para ellos. Puedes agregar enlaces. Puedes agregar ejemplos. Tienes todo el poder de markdown a tu disposición. Puedes agregar valores predeterminados. Puedes agregar la versión en la que se introdujo algo en el proyecto. Cualquier otra cosa que puedas pensar o considerar, jsdoc, son estándares realmente maduros. Y no hay nada mejor que poder ver la documentación de lo que estás usando en tu IDE en lugar de tener que ir a otro lugar o realizar una búsqueda rápida. Incluso puedes alojarlo de esa manera. Echa un vistazo a jsdocs.io. Puedes escribir cualquier paquete y ellos mostrarán la documentación basada en los archivos de declaración de ese proyecto. Incluso puedes considerar algo como unpiped, que es un paquete en la organización onjs.github que te permite tener un esquema de configuración con tipos. Puede que no sea relevante para tu proyecto, lo usamos en Nuxt. Podemos tipar nuestro esquema de configuración y luego exportarlo a json o a código. Podemos hacer cosas con él, como generar documentación de forma programática. Eso es lo que usamos para asegurarnos de que nuestra documentación de configuración de Nuxt sea precisa y esté actualizada en el sitio web. Siempre se basa en el código real y el JSTOC en ese archivo de código. Aquí hay un pequeño ejemplo seleccionado de una biblioteca que mantengo. No es complejo, no es difícil como autor hacer esto.

3. Using TypeScript for Documentation and Testing

Short description:

TypeScript te permite agregar solo los valores requeridos, proporcionando una representación realista de la funcionalidad. Probar tus tipos junto con las pruebas unitarias garantiza una tipificación precisa. Herramientas como Unbuild ayudan a probar los archivos compilados, asegurando precisión en el desarrollo. La versión de los tipos es esencial, ya que los cambios pueden romper el código del usuario o la compilación.

No necesitas escribir todos los tipos, TypeScript te respalda en ese sentido. Puedes agregar solo el valor que se requiere. Un ejemplo de cómo se podría usar algo, una explicación adicional de qué podría ser un parámetro en particular, luego obviamente alguna declaración general, y solo mira cómo se muestra. ¿No es hermoso? ¿No muestra algo que podría ser realmente útil como usuario de ese código?

Entonces ahí lo tienes, los tipos como documentación. Pero creo que otro punto de este concepto de verdad es que no solo estamos exponiendo nuestro código en tiempo de ejecución, también estamos exponiendo nuestros tipos como una biblioteca. Eso también es nuestro código, lo que significa que la implicación número uno es que debemos probarlos. Me gusta especialmente expect type como biblioteca, y eso es lo que estás viendo aquí, pero test también es una gran herramienta que he usado en otros proyectos. Entonces, en realidad, puedes probar tus tipos junto con tus pruebas unitarias normales con algo como expect type. Así puedes reducir el enfoque en un valor de retorno específico y realmente esperar que ese valor sea el tipo que deseas. Para que esto funcione, solo necesitas ejecutar ESC y noemit en tus archivos de prueba, además de ejecutarlos con tu ejecutor de pruebas, vtest o simplemente o lo que sea. Y no olvides el hecho de que TypeScript en sí mismo también puede ayudarnos. Es particularmente útil tsexpect error, que lanzará un error si no hay un error en la línea siguiente. Es un gran ejemplo de decir que esto debería generar la línea ondulada roja cuando mis usuarios hacen algo como esto porque no debería permitirse. Entonces, entre expect typeof, que viene con una gran cantidad de funciones auxiliares que se pueden encadenar a partir de él, y tsexpect error, puedes tipificar tu código de manera bastante precisa, crear una interfaz de tipo para tus usuarios. Creo que eso es absolutamente esencial para un autor de biblioteca. También recomendaría como seguimiento de eso probar tus archivos compilados porque a veces puedes tener una situación en la que los archivos fuente están bien desde el punto de vista de la tipificación. No es hasta que se construyen las cosas que surge algún tipo de problema. Y para ayudar con eso, existen herramientas como Unbuild y otras que te permiten tener un modo de simulación para que tus archivos dist en desarrollo apunten efectivamente a tus archivos fuente. Unbuild escribe stubs que funcionan en node, por lo que puedes usarlo en desarrollo. Pero también significa que obtienes los archivos compilados precisos cuando realmente construyes tu proyecto. Siempre y cuando en tus pruebas importes desde tu biblioteca compilada. Solo escribe el nombre completo de tu proyecto y asegúrate de tener una entrada en tsconfig o hayas configurado un alias en tu ejecutor de pruebas y de esa manera siempre puedes probar tus archivos compilados en tus pruebas de tipo. Otra implicación si los tipos son código, versionarlos. Adhiérete a semver si puedes. Por ejemplo, podrías lanzar una mejora en tu proyecto. Normalmente, una mejora no desencadenaría un cambio que no rompa la compatibilidad. Pero si cambia tu tipo de manera que algo se rompa para tus usuarios o la compilación se rompa en ese proyecto, entonces es un cambio que rompe la compatibilidad. Un ejemplo sería, tengo que admitirlo aquí, hice un PRN a definitely types para cambiar el tipo de end y algunos otros tipos relacionados con stream, y parece que había una pequeña discrepancia entre la realidad y los tipos de node. Res end devuelve esto, no void, así que queríamos corregir eso. Pero solo mirando las implicaciones de

4. Managing Changes and Exposing Types

Short description:

Realizar cambios en los tipos requiere una cuidadosa consideración y una correcta versión. Herramientas como API Extractor pueden ayudar a mantener los contratos de tipos. La deprecación de tipos y la adición de sobrecargas de funciones pueden minimizar el impacto en los mantenedores de bibliotecas. Es crucial exponer solo los tipos previstos. El uso de herramientas de compilación como rollup-plugin-dts o dts-bundle-generator puede controlar el acceso a los tipos. Los tipos sirven como documentación, código y verdad, y no deben usarse para engañarnos a nosotros mismos o a los usuarios.

que lo cambian fue enorme. De repente, los flujos que se estaban pasando no podían ser pasados a funciones que esperaban el antiguo tipo de flujo. Así que hacer ese cambio fue un cambio que rompió para mucha, mucha gente. Probablemente aún tenía que hacerse, pero tienes que tener mucho cuidado al respecto. Y requiere mucho esfuerzo asegurarse de que versiones tus tipos correctamente. Considero una herramienta como API Extractor. Es increíblemente completa. Es un poco compleja de configurar, pero puede ayudar a garantizar que tus contratos de tipo no cambien, que puedas cumplir cuando estás lanzando nuevos cambios a los tipos. Y obviamente, hay cosas que puedes hacer cuando estás haciendo cambios para asegurarte de que no sean cambios completos, sino que las cosas sean un poco más suaves. Por ejemplo, puedes simplemente deprecar un tipo si lo estás renombrando. Así, los usuarios tienen algo de tiempo para cambiar su uso. Y puedes hacer algo similar, con funciones, en lugar de simplemente cambiar el tipo de la función. Nuevamente, esto puede que no sea necesario. Pero en algunos casos, podría serlo. Puedes agregar una sobrecarga, para que la función continúe teniendo la firma anterior, pero también tenga una nueva firma y maneje ambas. Entonces, hay algunas cosas que puedes hacer, creo, para reducir el impacto en ti como mantenedor de biblioteca al tener que lanzar nuevas versiones menores o mayores cuando estás cambiando tus tipos.

También vale la pena decir que si tus tipos son tu código, si los consideras como tu API y un contrato con tus usuarios, es realmente importante que solo expongas los tipos que pretendes. Habrá muchos tipos internos, tipos que estás utilizando con fines de utilidad. Puede haber código de utilidad que sea solo interno. Por defecto, TypeScript hace algo que encuentro incomprensible, y es que obviamente representa la estructura completa de tu proyecto en archivos de declaración. Entonces, los usuarios pueden, agregando la ruta a tus archivos fuente, acceder a los tipos y las declaraciones de cada función y tipo que se exporta en cualquiera de tus archivos fuente, incluso si no se exporta desde tu punto de entrada y paquete final. Entonces, usar algo como rollup-plugin-dts o dts-bundle-generator significa que puedes agruparlo para que no sea accesible desde tu index.d.ts final. Eso es algo muy útil en conjunto con todo lo demás de lo que he estado hablando en términos de pruebas y versionado de tus tipos. Ya existen muchas herramientas de compilación que hacen esto por ti, incluido Unbuild, que mencioné anteriormente. Y finalmente, no solo se trata de tipos como documentación o tipos como código, sino que llegamos al punto real, los tipos como verdad. Perdona el punto filosófico o epistemológico. Creo que de eso se trata los tipos. Se trata de exponer la realidad del proyecto, de tu biblioteca, de cómo funciona y qué hace. Y la consecuencia es que debemos evitar la oportunidad de mentirnos a nosotros mismos y a nuestros usuarios. Porque hacemos esto todo el tiempo, y yo soy muy propenso a esto, es muy fácil poner un as o escribir algo como any. Es muy posible desactivar las comprobaciones estrictas de nulos y simplemente disfrutar de

5. Strictness and Deep Integration of Types

Short description:

Los autores de bibliotecas deben ser estrictos y garantizar tipos confiables para los usuarios. La inferencia de TypeScript se puede utilizar para determinar los tipos de retorno, pero es necesario realizar pruebas para garantizar la precisión. Ir más allá de los tipos superficiales a aquellos que se integran profundamente con la biblioteca mejora la usabilidad. Por ejemplo, el uso de literales de cadena en lugar de cadenas genéricas permite valores más específicos. Un ejemplo de la biblioteca OhMyFetch demuestra cómo se pueden configurar los tipos de respuesta en función de las preferencias del usuario.

el hecho de que no tengas que... simplemente asumes que se establecerá. Pero creo que la disciplina para los autores de bibliotecas es ser lo más estrictos posible, para que lo que estamos generando y declarando a nuestros usuarios sea confiable según su criterio. No deberían tener que probarlo por nosotros. Deberíamos haberlo probado completamente para que nuestros tipos sean precisos. En la medida de lo posible, me gusta el paradigma llamado fuente de verdad, donde efectivamente tienes la fuente de verdad proveniente de donde algo es... del código real que procesa lo que se ejecuta en una función. En lugar de tener una función y declarar manualmente el tipo de retorno. Sé que las personas tienen diferentes puntos de vista. Prefiero permitir que TypeScript infiera ese tipo de retorno. Pero luego probarlo, como he estado diciendo. Para asegurarnos de que lo que estamos obteniendo no cambie inesperadamente, no se convierta en any, no tenga un void inesperado. Pero en lugar de escribirlo manualmente, o peor aún, usar as para hablar sobre el tipo de retorno, simplemente nos aseguramos de que lo que TypeScript está inferiendo es lo que pretendemos analizar. Eso significa que no estrechamos inesperadamente un tipo, por ejemplo. O no convertimos inesperadamente algo en un tipo cuando no teníamos la intención de hacerlo. Y luego, creo, probablemente el cambio de paradigma más significativo como autor de bibliotecas es pasar de lo que podríamos llamar un uso superficial de tipos a tipos que realmente penetren en el núcleo de tu biblioteca. Entonces, no solo describir algo. Puede que tengas un parámetro que sea una cadena. Describirlo como una cadena puede que no sea tan útil. Pasa de una cadena a un literal de cadena ya es mucho mejor porque estás diciendo que se pueden pasar estos valores específicos a mi biblioteca. Eso te permite hacer algo mucho más útil para tu usuario final. Toma este fragmento de código como ejemplo. Esto se toma y se simplifica ligeramente de una biblioteca llamada OhMyFetch. Es una capa conveniente sobre la API fetch. Una de las cosas que te permite hacer es pasar como opción qué tipo de respuesta te gustaría recibir. ¿Quieres obtener una respuesta JSON? Bueno, ese es el valor predeterminado. Pero es posible que desees acceder a un búfer de matriz o a un blob o simplemente a la cadena que se devuelve. Y queremos poder configurarlo. Pero obviamente, eso cambiará el tipo de la respuesta. Si dices que quieres un búfer de matriz, el tipo que obtienes debería ser una matriz

6. Implementando Personalización con un Mapa

Short description:

El uso de un mapa en TypeScript en lugar de una cadena de extensiones permite una implementación y personalización más sencillas. La magia del tipo mapeado permite devolver el tipo real en función de la cadena pasada. Este enfoque proporciona un conjunto predeterminado agradable de respuestas completamente tipadas, asegurando una coincidencia precisa de los tipos de retorno esperados.

búfer. No debería ser otra cosa. No debería permitirte anular ese tipo con algún tipo personalizado. Y acabamos de implementar esto de manera bastante sencilla con un mapa, que a menudo es un buen patrón en TypeScript. En lugar de una cadena de extensiones, en realidad solo puedes tener un mapa y escribir un solo extends y devolver lo que deseas. Extends, por cierto, es una de las herramientas más poderosas para este tipo de personalización del que estamos hablando aquí. Y este código en particular define esas utilidades para nosotros. Entonces, aquí está el mapa entre la cadena de texto blob búfer de matriz y el tipo real que va a regresar. Luego permitimos JSON, que es un poco comodín en este caso particular, porque realmente puede ser cualquier cosa. Queremos que el usuario pueda proporcionar una anulación que coincida con lo que realmente está regresando. Y luego tenemos esta magia del tipo mapeado, que nos permite devolver si el usuario pasa, supongo que somos los consumidores de eso. Pasamos texto o búfer de matriz, va a devolver el tipo real que coincide con esa cadena. Y así, luego podemos juntarlo todo en la interfaz para fetch allí, que es lo que sea que sean esas opciones, si el tipo de respuesta es texto, obtenemos una cadena promesa. Si es un búfer de matriz, obtenemos una promesa de búfer de matriz. Y si es JSON, entonces devolvemos desconocido o permitimos que el usuario anule eso. Y así, obtenemos un conjunto predeterminado de respuestas completamente tipadas. Eso es a lo que me refiero con adentrarse en el núcleo de la biblioteca. Y estoy seguro de que eso se podría mejorar mucho. Pon un PRN si quieres. Pero ese tipo de movimiento de decir, no solo quiero devolver el tipo búfer de matriz o blob o cadena o desconocido. En realidad, quiero asegurarme de que lo que estoy devolviendo coincida de manera muy precisa, tanto como sea posible, con la cosa real que regresará dado ese conjunto de entradas a eso

7. Consejos para lograr especificidad en la respuesta

Short description:

Para devolver una respuesta específica según la entrada del usuario, se puede utilizar la inferencia de tipos y una función auxiliar sin operaciones. Al extender la interfaz de opciones, se puede lograr una funcionalidad más compleja. La normalización de la entrada del usuario y su accesibilidad con fines de tipo es crucial.

función. Entonces, algunos tips, creo, para lograr eso. Entonces, uno, es un patrón muy común ahora, y creo que es necesario. Para acceder a toda la información que pueda necesitar para devolver una respuesta específica según lo que el usuario le está proporcionando, a menudo es necesario utilizar la inferencia de tipos, que es realmente utilizable a través de funciones. Entonces, una función sin operaciones que dice, bueno, el usuario está pasando algo, y no sé exactamente qué es, pero debería coincidir con el paradigma de opciones. Pero no solo diciendo que es esta interfaz de opciones, sino que la extiende, podemos hacer cosas mucho más interesantes con ella más adelante. Como decir, si esta opción es este valor, vamos a devolver esto. O si esa opción es este valor, entonces esta otra opción debe coincidir de esta manera. Entonces, es posible que necesite utilizar ese tipo de función auxiliar sin operaciones y tener una configuración definida o opciones definidas o una interfaz definida, un esquema definido. Lo que sea que esté produciendo, tener este tipo de paso intermedio donde el usuario proporciona algún tipo de entrada y lo normaliza, pero lo hace accesible para sí mismo con fines de tipo.

8. Aprovechando los Tipos para Beneficios de la Biblioteca

Short description:

Los tipos pueden hacer todo el trabajo por ti, guiando a los usuarios para que solo escriban lo que coincide con el objeto fuente. Al mover el trabajo de tiempo de ejecución a la escritura de tipos, puedes generar código basado en el acceso del usuario. En Nuxt, los componentes y complementos están tipados para que coincidan con la realidad del usuario. La detección automática de tipos permite valores inyectados en las plantillas. La escritura de tipos en TypeScript puede revelar valores de retorno de funciones específicas. Las rutas de API tipadas permiten la definición de controladores de eventos en el lado del servidor.

es a menudo realmente, realmente crucial. Muy importante. En algunos casos, vale la pena destacarlo. Los tipos pueden hacer todo el trabajo por ti. Esto puede ser donde proviene el beneficio real de tu biblioteca. Por ejemplo, tienes un objeto pasado. TypeScript es capaz de puedes escribir tipos que transmitan el comportamiento que deseas. Y luego puedes tener algo como un proxy que haga el trabajo real. Entonces, tal vez estés mapeando valores del objeto a algo más y usando una notación de puntos anidados. En realidad, puedes permitir que el tipo sea la guía para el usuario. Entonces, solo pueden escribir los tipos de cosas que coinciden con el objeto fuente. Y luego en tu código, tienes un proxy que solo observa qué valores realmente accede el usuario. Qué propiedades de el objeto a las que acceden. Y luego realmente puedes generar el código y hacer lo que ellos pretenden hacer de esa manera. Creo que eso es bastante divertido, cuando mueves el trabajo del tiempo de ejecución a la escritura de tipos. Aquí tienes un ejemplo de lo que hemos hecho en Nuxt. Entonces, en Nuxt, hemos intentado que la escritura de tipos coincida lo más posible con la realidad para el usuario. Entonces, tenemos el concepto de componentes que son accesibles en cualquier lugar de la aplicación. Entonces, mi componente debería ser accesible aquí. Y de hecho, lo es. Tenemos el tipo generado aquí automáticamente, para que el usuario pueda ir directamente a él con el complemento Vue que recomendamos. Los complementos mismos pueden inyectar valores en la instancia de la aplicación Nuxt y en la instancia de Vue para que puedan ser accedidos en la plantilla. Y nuevamente, admitimos la detección automática de tipos para eso. Entonces, el usuario puede decir, estoy inyectando Fu, y en la plantilla, lo tenemos disponible para el usuario como una propiedad que ha sido inyectada. TypeScript es un poco más inteligente cuando estás escribiendo una función. Puedes ver el valor específico que se devuelve al final, debería ser world. Lo cual, creo, es bastante genial. También tenemos rutas de API tipadas. Cuando estás definiendo un controlador de eventos en el lado del servidor de tu aplicación. Este es solo un ejemplo bastante simple con una cadena. Pero puedes tener algo

9. Integración de TypeScript y Nuxt

Short description:

Conocemos el valor de retorno al obtener un punto final. Los componibles se importan automáticamente en toda la aplicación, brindando ayuda y soporte al usuario. Nuxt escribe declaraciones de tipo en segundo plano y las expone al editor para brindar soporte mientras se escribe. No dudes en contactarnos para obtener más información sobre la integración de Nuxt y las herramientas de TypeScript.

eso es mucho más complejo. Y en realidad, podemos decir, bueno, en realidad sabemos qué será el valor de retorno. Entonces, cuando obtienes ese punto final, sabemos que su respuesta será esa cadena simple. Muchos otros ejemplos. Los componibles podrían ser útiles. Tenemos un concepto de componibles importados automáticamente en toda tu aplicación. Entonces, nuevamente, hacemos que ese tipo esté disponible globalmente en toda la aplicación. Entonces, si el usuario simplemente escribe `úsame en cualquier lugar`, obtendrán la respuesta del componible real. Entonces, nuevamente, en la medida de lo posible, lo que estamos tratando de hacer es brindar ayuda y soporte para el entorno real con el que están interactuando. En este caso, su entorno, nuxt, importará automáticamente estas cosas y las pondrá a su disposición en cualquier lugar. Por lo tanto, el usuario no debería tener que hacer nada adicional para eso. Y si estás interesado en saber cómo funciona nuxt, básicamente está escribiendo declaraciones de tipo en segundo plano y exponiéndolas al editor para que el editor pueda brindar el tipo correcto de soporte mientras escribes. Lo cual creo que es bastante genial. Me encantaría responder cualquier pregunta que puedas tener al respecto más adelante. Bueno, si estás interesado en algo de lo que he estado hablando, ya sea la integración de nuxt o algunas de las herramientas que tenemos a nuestra disposición en TypeScript para brindar a los usuarios una gran experiencia al usar nuestras bibliotecas, no dudes en escribirme, seguirme en Twitter, y especialmente si estás interesado en nuxt, consulta la documentación, mira algunas de las cosas que hemos hecho con los tipos. Me encantaría explicarte eso. Síguenos en Twitter o únete a Discord y no dudes en enviarme un mensaje directo con cualquier pregunta que puedas tener. Ha sido un verdadero placer y espero que tengas un excelente resto de tu conferencia.

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

JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
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.
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
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 Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
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.
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
JSNation 2022JSNation 2022
141 min
Going on an adventure with Nuxt 3, Motion UI and Azure
WorkshopFree
We love easily created and deployed web applications! So, let’s see what a very current tech stack like Nuxt 3, Motion UI and Azure Static Web Apps can do for us. It could very well be a golden trio in modern day web development. Or it could be a fire pit of bugs and errors. Either way it will be a learning adventure for us all. Nuxt 3 has been released just a few months ago, and we cannot wait any longer to explore its new features like its acceptance of Vue 3 and the Nitro Engine. We add a bit of pizzazz to our application with the Sass library Motion UI, because static design is out, and animations are in again.Our driving power of the stack will be Azure. Azure static web apps are new, close to production and a nifty and quick way for developers to deploy their websites. So of course, we must try this out.With some sprinkled Azure Functions on top, we will explore what web development in 2022 can do.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.