Generando tipos sin trepar un árbol

Rate this content
Bookmark

¿Cómo generas tipos dinámicamente? ¿Cómo escribes un script que crea código TypeScript? El enfoque que la mayoría de las personas recomendaría es utilizar manipulaciones del Árbol de Sintaxis Abstracta. Estaba trabajando con una fecha límite para implementar tipos para nuestro cliente OpenAPI, y habría perdido nuestra ventana de lanzamiento. Necesitaba algo diferente y más fácil de construir. Afortunadamente, un amigo me recomendó una biblioteca que no conocía: code-block-writer. Me enamoré de ella a primera vista.

30 min
21 Sep, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Esta charla explora los desafíos y beneficios de generar tipos para APIs. El orador discute la necesidad de una mejor experiencia para el cliente y la popularidad de generar clientes. También explica el uso de OpenAPI para generar clientes de API REST y el uso de Cold Block Writer para la generación de código. La charla cubre el proceso de definir tipos para parámetros y respuestas, generar el cliente y la solicitud, y utilizar el cliente generado. El orador también menciona la validación en producción y los desafíos iniciales con TypeScript.

1. Introducción a la Generación de Tipos

Short description:

Hola a todos. Soy Matteo Collina, cofundador y CTO de Platformatic, y hoy voy a hablar de algo que me pone un poco nervioso, la generación de tipos. Entradas. ¿Por qué? Vamos a profundizar en ello. Así que, la primera pregunta para todos ustedes es, ¿cuántas cuerdas necesitan para subir a un árbol? Esta es una pregunta fundamental y vamos a intentar responderla en esta charla.

hablar de algo que me pone un poco nervioso, la generación de tipos. Entradas. ¿Por qué? Vamos a profundizar en ello. Así que, la primera pregunta para todos ustedes es, ¿cuántas cuerdas necesitan para subir a un árbol? Esta es una pregunta fundamental y vamos a intentar responderla en esta charla. Así que, vamos. Lo primero, un par de cosas sobre mí. Soy Matteo Collina, parte del Comité de Dirección Técnica de Node.js, también miembro de la Junta Directiva de la Fundación Open Source Open JS. He creado un montón de bibliotecas, ayudado a mantener nodos, probablemente usando algunas de mis software dado que se descargaron 17 mil millones de veces el año pasado, así que sí, tal vez. Así que, algunas de mis decisiones afectan a algunas personas, así que espero no romper a demasiados de ustedes durante esta charla o después. De todos modos, vamos y saltemos. He escrito muchos módulos, mantengo muchos módulos en NPM, muchas descargas, lo que sea que importe. Por cierto, si alguna vez usas uno de ellos, si quieres patrocinarme en GitHub, todo es apreciado. Tengo una pequeña confesión que hacer. ¿Qué? ¿Qué? Bueno, antes de 2022, casi nunca usé TypeScript. Y aquí estoy hablando en el Congreso de TypeScript. ¿Qué es eso? Es realmente fascinante. Evité y pasé por alto esta tecnología tanto tiempo como pude. ¿Qué pasó en 2022? Bueno, empecé una nueva empresa, y era una experiencia de desarrollo para empresas. Así que sí, tuve que adentrarme en TypeScript. De hecho, todo se basa en algo que había hecho anteriormente, que es Fastify, que es un proyecto dentro de la Fundación Open Source también. Y se trata de construir APIs. Soy un ingeniero de back-end de profesión y lo que quiero es ayudar a las personas y cómo ayudar a las personas con mi herramienta, ya sabes, para construir y usar APIs de manera mejor y hacerlo más rápido y más fácil de desarrollar, mantener, escalar, como quieras llamarlo. Así que sí, típicamente el flujo típico cuando uno de tus miembros del equipo o alguien más está comenzando a escribir tus APIs, tienes una API en un extremo y típicamente eres un ingeniero de back-end escribiendo algunas consultas SQL complejas o algunas consultas complejas de MongoDB, lo que quieras, luego generan, escriben algo de documentación a partir de esa API y luego tu cliente, tu ingeniero, codifica su cliente. Entonces, ¿cómo se relaciona esto con la generación de tipos? Sí, permítanme presentar el problema primero. Esto es más o menos lo que Plasformatic quiere simplificar y mejorar cómo creamos software de back-end. Típicamente lo que queremos hacer es mover, permitirte moverte muy rápidamente de A a B utilizando tantos rieles como sea posible, rieles de protección para todos ustedes para moverse muy rápido. Y luego, ya sabes, puedes llevar tu viejo SUV exactamente donde quieras ir. Así que, queremos ayudar a los desarrolladores a deshacerse de todo el trabajo pesado indiferenciado de construir tus aplicaciones JS. Como parte de eso, en algún momento, nos enfocamos en trabajar

2. The Need for a Better Client Experience

Short description:

Lo que descubrimos al hablar con mucha gente fue que tener un cliente para las APIs era fundamental para una buena experiencia de desarrollo. La generación de clientes se ha vuelto popular recientemente con bibliotecas como tRPC y TS Rest. Sin embargo, estas bibliotecas introducen un acoplamiento estrecho entre el cliente y el código del servidor, lo que dificulta la escalabilidad y la evolución. Necesitamos una mejor experiencia de cliente que permita flexibilidad y el uso de diferentes versiones de TypeScript.

mucho en las APIs y mejorar dos APIs que se habían escrito. Lo que descubrimos al hablar con mucha gente fue que, ya sabes, oh, pero tener un cliente para esas APIs era realmente fundamental para proporcionar una buena experiencia y agilizar el desarrollo. Entonces, lo que sucedió fue que, ya sabes, a la mayoría de las personas realmente les gusta mucho más este flujo. Así que, en lugar de tener que llamar al cliente y preparar documentation para la API, solo quiero presionar un botón y generar un cliente. De hecho, esto ha sido tan popular desde hace mucho tiempo, y de alguna manera lo perdimos un poco en el camino, porque, ya sabes, recuerdo generar clientes para mis APIs cuando hacía WSDL y SOAP hace mucho tiempo. Así que, ya sabes, probablemente no sea una gran comparación, pero lo es. De todos modos, esto ha sido extremadamente popular recientemente. De hecho, esto ha sido popularizado en gran medida por algunas bibliotecas nuevas. Una es tRPC, que es fantástica, proporciona una experiencia de developer experience fantástica. Te permite exponer tu... crea una llamada RPC desde el servidor al... desde el cliente al servidor de una manera completamente segura en cuanto a tipos. Es genial, ¿vale? Solo tiene una desventaja significativa, que es el acoplamiento de tipos introducido en el... el código de tu frontend con el código de tu backend, también utiliza un protocolo propietario para comunicarse. Así que sí, es muy estrecho. Es un acoplamiento muy estrecho entre el cliente y el servidor. Hay otra biblioteca llamada TS Rest, que también es genial, una biblioteca fantástica, pero tiene otro pequeño... todavía otro pequeño problema, que es que necesitas especificar el contrato entre tu cliente y tu servidor en su propia definición de espacio de tipos. Nuevamente, para consumir la biblioteca, necesitas tener una dependencia de código fuente en el servidor. Así que nuevamente, para mí, esto introduce un acoplamiento estrecho entre los dos. De hecho, el problema aquí es el concepto de ya sabes, lo que sucede en la mayoría de los equipos con los que he trabajado y desarrollado y demás, es que básicamente tienes alguna API que es desarrollada más o menos por un equipo y hay otro grupo de personas que, ya sabes, crea y consume o que consume esas APIs. Y esos grupos típicamente están más o menos separados en la mayoría de las empresas y en la mayoría de las organizaciones. Entonces, integrar todo junto, crear un acoplamiento estrecho entre todo eso hace que sea muy difícil descomponer y escalar y seguir evolucionando las cosas. Y por cierto, no hay nada que criticar a esas bibliotecas, que son fantásticas. Solo estoy hablando de por qué creo que necesitamos una mejor experiencia de cliente para las APIs. Entonces, ¿dónde nos quedamos? Bueno, algo que queremos proporcionar es una experiencia de desarrollador fantástica pero sin ningún acoplamiento estrecho. Entonces, sin ningún código compartido, esencialmente, entre el servidor y el cliente, para que puedas usar y consumir otras APIs. Y así, uno puede usar TypeScript 4.9 y el otro puede usar TypeScript 6 en el futuro. Y pueden evolucionar y tener diferentes versiones, diferentes cosas. Todo es divertido y perfecto. Entonces, ¿cómo podemos generar esta developer experience? Comencé este viaje,

3. Generación Automática de Clientes REST API

Short description:

Y como parte de este viaje, una encuesta mostró que el 80% de los desarrolladores prefieren REST en lugar de GraphQL. Mi viaje comenzó con la pregunta de cómo generar automáticamente un cliente mínimo y sencillo para las APIs REST. OpenAPI, un estándar, proporcionó una solución fantástica. Usando Fastify o plataforma, podemos generar fácilmente documentación y definiciones de especificaciones OpenAPI. El cliente tenía requisitos específicos: fácil consumo en el frontend, validación de datos en tiempo de ejecución, completamente tipado para detectar errores de los desarrolladores y sin dependencias en tiempo de ejecución. Mi primer intento de generación de código resultó complejo y difícil de depurar.

Uno de los tipos de trabajo de mi viaje fue esta pregunta. Y como parte de este viaje, hubo un poco de una encuesta que muestra que más o menos el 80% de los desarrolladores prefieren REST en lugar de GraphQL, lo cual suena muy poco intuitivo para mí, pero así es. Y si tienes mejores datos que esto, por favor avísame, porque esto es algo que me intriga mucho. Entonces, mi viaje comenzó con la pregunta de cómo podemos generar automáticamente un cliente para nuestras APIs REST. Y el código generado debería ser mínimo y sencillo. ¿Cómo podemos lograr eso? Bueno, algo muy fantástico fue que OpenAPI es un estándar. Y construí este framework llamado Fastify, que es un framework realmente bueno. Está ganando cada vez más atención en estos días sobre cómo construir APIs en Node.js. Y puedes obtener fácilmente una documentación OpenAPI o swagger, como se llamaba anteriormente, generada muy, muy rápidamente sobre tus rutas. Así que podemos obtener la documentación, pero también la definición de especificaciones para OpenAPI. Así que tenemos todo, podemos obtener esto en su mayoría de forma gratuita usando Fastify o usando plataforma. Entonces, el cliente, de hecho, tenía algunos requisitos para mí. Y uno de ellos era, bueno, tengo mis rutas definidas usando OpenAPI y quiero consumirlas muy fácilmente en el frontend. Realmente no quiero que ocurra ninguna validación de datos en tiempo de ejecución, o tal vez debería estar desactivada, está bien, porque no quiero perder tiempo en el cliente. Quiero que mi código sea lo más ágil posible. Pero también quiero que esté completamente tipado para detectar errores de los desarrolladores en el editor. Y quiero usar fetch, por lo que no tengo ninguna dependencia en tiempo de ejecución. Así que solo necesito obtener mi archivo generado, y eso es todo. Mi primer intento de generar este código fue usar. Así que comencé a usar esta generación de código. ¿Cómo puedo obtener el código que generó mi código generado? Y leí un buen artículo en DevTool. Comencé a hacer muchas cosas y quería hacer. Hagamos un experimento. Generemos esta función muy, muy simple y este código a la derecha. Es lo que se necesita para generar esa función. Ahora mira el código. En realidad es complejo. Puedes leer lo que hace. Creo un identificador, creo la función, hace todas las cosas, pero es muy, muy difícil... Si hay un problema allí, en realidad es muy, muy difícil de depurar. También requiere mucho código.

4. Generación de TypeScript y Uso de Cold Block Writer

Short description:

Pensé que podría generar TypeScript fácilmente, pero parece una tarea enorme. Sin embargo, encontré una biblioteca llamada Cold Block Writer que facilita la generación de código. Tiene una propiedad llamada block que permite la inserción automática de llaves y gestiona la indentación. La desventaja es que el código generado puede no ser válido, pero es una opción más pequeña y conveniente. Podemos usar la especificación OpenAPI para generar nombres de funciones basados en la ruta y el ID de operación.

Para generar muy pocas líneas. Así que no estaba necesariamente muy... Oh, estaba... Oh, ouch. ¿Cómo puedo... Pensé que podría generar TypeScript fácilmente, pero ¿cómo puedo obtenerlo? Parece que es un árbol enorme que tengo que escalar y no pude hacerlo en mi línea de tiempo, así que pensé, tal vez no. No quería escalar ningún árbol, pero esto parece un árbol enorme para escalar, así que, ouch, ¿cómo puedo hacerlo? Así que hice otro intento. Hice algunas búsquedas y probé otra vez y encontré esta biblioteca llamada Cold Block Writer, que es absolutamente algo que es realmente, realmente bueno. Y creo que deberías echarle un vistazo a Cold Block Writer si estás intentando generar código dinámicamente. ¿Por qué? Porque tiene una propiedad muy, muy buena aquí. Si miras el código a la derecha, es básicamente homomórfico en el sentido de que el código, en cómo escribimos la función, es muy, muy similar al código generado que queríamos tener. Debido a que hay una homomorfía entre esas dos cosas, en realidad podemos encontrar errores y solucionarlos muy fácilmente porque, oh, estas son las tres líneas que generan el mismo código. Puedo ver estas tres líneas y esas líneas. Así que, en realidad, es muy útil, muy fácil de escribir porque tiene esta propiedad llamada block que nos permite crear llaves automáticamente. ¡Hey, genial! Y también genera y gestiona la indentación automáticamente. Realmente me gusta esta biblioteca. Solo tiene una gran desventaja. El código generado no está garantizado que sea válido. También es mucho más pequeño, por lo que si quisiera reducir el compilador de TypeScript, como 50 y pico de megabytes, lo están reduciendo. Así que, tal vez ahora sea 30. No sé. De todos modos, es una dependencia masiva, el compilador de TypeScript, pero este es realmente muy pequeño también. Así que, en realidad, es muy agradable y genial. Parece una opción perezosa aquí. Y soy un desarrollador perezoso, así que empecé a pensar, hagamos eso. Hagamos perezoso. De acuerdo. Y echemos un vistazo a la especificación OpenAPI y cómo genera el código. Qué código queremos generar. Así que, mira, la especificación OpenAPI, tiene una propiedad de ruta y dice que hay una barra diagonal películas, por ejemplo. Y cada ruta tiene un ID de operación. Y este ID de operación, podemos usarlo para generar los nombres de nuestras funciones. Entonces, cuando alguien quiera llamar a la función wait get movies,

5. Definición de Tipos para Parámetros y Respuestas

Short description:

Podemos definir y generar tipos para cada parámetro y respuesta en la especificación OpenAPI. Esto nos permite generar interfaces y utilizarlas en nuestra API.

por ejemplo, podemos llamar automáticamente al punto final de películas. ¿De acuerdo? Además, ha definido sus parámetros y respuestas. Sí, es genial. ¿De acuerdo? Y luego podemos hacer lo mismo exactamente para cada una de las otras operaciones que están definidas en mi especificación OpenAPI. De hecho, incluso podemos, ya sabes, incluso podemos, ups, lo siento. Incluso podemos, ya sabes, verificar y definir los tipos y generar los tipos para cada uno de nuestros parámetros y respuestas. Si lo miras, en realidad es bastante genial. ¿De acuerdo? Y tenemos todos los parámetros definidos y luego tenemos todas nuestras respuestas definidas. Así que podemos generar interfaces para ambos.

6. Generando el Cliente y la Solicitud

Short description:

Entonces tenemos create movie y hay una solicitud create movie que devuelve una respuesta. Hemos dividido los tipos de nuestras APIs con las interfaces reales, lo que permite una mejor manipulación. El código generado es muy simple y se puede generar rápidamente. Hagamos una demostración rápida para ver lo fácil que es. Creamos una pequeña API, la iniciamos y generamos el cliente usando TypeScript. El cliente se basa en fetch y no tiene dependencias. Tenemos una solicitud get movie en el archivo api.types.

y los usamos como parte de nuestra API. Entonces tenemos create movie y hay una solicitud create movie que devuelve una respuesta. Parece bien. Entonces creo que esto es, sabes, para mí, uno de los puntos interesantes aquí es que ves aquí hemos dividido, ups, lo siento. Hemos dividido aquí los tipos de nuestras APIs con las interfaces reales. De esta manera, las cosas se pueden manipular mejor, creemos. De todos modos.

Algunas de las buenas, hay algunas buenas ideas aquí, pero el código generado es en realidad muy, muy simple. Como puedes mapear con uno a uno a lo que necesitas. Y creo que fue, podríamos generar este cliente muy rápidamente. Así que hagamos una pequeña demostración rápida. Y para que podamos ver lo fácil que es hacer cosas. Así que creemos un poco de una pequeña API, para que podamos hacer create platformmatic. Y aquí vamos. Queremos estar aquí, nuevo SQLite, pero podríamos usar cualquier cosa. Ups, lo siento. Y sí, sí. Y no por ahora, porque no quiero hacer NPM install. Así que estoy creando automáticamente una API muy rápidamente. Y sabes que ahora mismo no necesito nada. Así que cuando inicio esto, podría aquí hacer un platformmatic start. Y si abrimos esto, está bien, y volvemos aquí, lo siento, aquí vamos, puedo ver exactamente lo que está sucediendo. Esto es lo que se carga y puedo abrir mi documentación OpenMPI documentation, y veo que tengo películas con todos mis parámetros, que podemos obtener automáticamente para crear todo. Entonces, ¿cómo usamos, cómo, ups, lo siento, cómo generamos el cliente? Ok, ups, lo siento, estoy... Entonces, ¿cómo generamos el cliente? Así que volvamos a cd client, ok, y aquí tenemos, preparé algo muy simple con un package json, vcsnode y typescript para no perder tiempo con npm install, así que ahora puedo hacer plt so-clear, y plt frontend, y necesito poner en la url de mi aplicación, y luego quiero generarlo como typescript, y nos ha generado dos archivos api-types.b.ts y api.ts, y tenemos dos de ellos, ok, y echemos un vistazo. Entonces este cliente es en realidad muy simple de usar, y tenemos uh tenemos aquí nuestro fetch. Así que necesito rts.config.json aquí, y necesito las opciones del compilador ok, y necesito el objetivo, y ok, de lo contrario las cosas serán incómodas. Aquí vamos, y comentamos atrás, ok, bien. Esto será incómodo, ok. De todos modos, lo que tenemos aquí, tenemos nuestro fetch. Así que todo se basa en fetch y en estándares. En realidad, no tenemos ninguna dependencia en absoluto, y luego en api.types, como mostré, tenemos nuestra solicitud get movie aquí

7. Using the Generated Client and Running the Test

Short description:

Entonces probemos y usemos esto y veamos cómo se ve la experiencia. Importamos desde api y usamos setBaseURL, create movie y get movies. Encontramos algunos elementos faltantes en createMovieRequest. Después de crear la película, recuperamos las películas y las registramos. Ejecutamos la prueba y todo funciona sin problemas. Usamos las funciones run, await y Start Wars. Vamos a ejecutarlo nuevamente.

que obtiene las cosas. Entonces sí, esto parece bastante bueno. Entonces probemos y usemos esto y cómo se vería la experiencia. Entonces, si abro test yes, puedo importar desde api. Y ahora puedo obtener setBaseURL y, por ejemplo, create movie y get movies. Ahora puedo hacer setBaseURL 0.3.0.4.2. Y luego queremos crear aquí, no existe, como ves aquí, no existe aquí, ¿de acuerdo? Y nosotros, no existe en createMovieRequest. Entonces, de hecho, si miramos los tipos aquí, si vamos a createMovie, lo siento. De acuerdo, createMovieRequest, ves que tiene un ID, un ID opcional y luego un título requerido. Entonces aquí está bien, pero luego necesitamos, hemos creado nuestra película y no necesitamos nada aquí. Entonces, de acuerdo, y luego podemos obtener las películas aquí y hacer console log, y necesito especificar algunos parámetros, pero en este caso están vacíos. Entonces, y hemos generado, hemos obtenido estas películas. De acuerdo. Y probemos esto. De acuerdo. Entonces, si hago TS node test. Ahora se está ejecutando. Genial. De acuerdo. Estoy ejecutando el precio. ¿Por qué se está ejecutando el precio? Porque estos dos, ya sabes, seamos amables. Seamos amables. Entonces la función run. Aquí vamos. Y creo que se ejecutaron en paralelo, ¿verdad? Entonces podemos hacer await. Y aquí hacemos Start Wars. Y aquí hacemos presionar await. Sí. Y luego run. Ahora podemos ejecutar esto nuevamente.

QnA

Generating the Client and Handling Internal Issues

Short description:

Tenemos Star Wars. Obtenemos el mismo resultado exacto. Esta es una forma bastante buena de generar un cliente. Funciona con cualquier OpenAPI compatible con cualquier sistema OpenAPI. Prueba nuestra herramienta de código abierto en docs.platformatic.dev. Gracias por recibirme en el S-Congreso.

Y aquí vamos. Ves que tenemos los dos que teníamos antes. Y ahora tenemos Star Wars. También podemos verificarlo muy rápidamente, si todo está correcto. Y está aquí, podríamos probar esto y ver si funciona correctamente. Como puedes ver, obtenemos el mismo resultado exacto. Y este es el código que se ejecutará y generará. Entonces no, creo que esto es bastante bueno. Es una forma bastante buena de generar un cliente. Como dijiste, aquí voy a dejarme hacer un árbol. Aquí no tenemos dependencias en absoluto, aparte de ts-node y cosas así, como si puedes ver, aquí solo tenemos ts-node y tipos. Entonces no hay otras dependencias en esos archivos. Es súper pequeño y basado en API. Entonces, el beneficio de este enfoque de usar OpenAPI es que funciona con cualquier OpenAPI compatible con cualquier sistema OpenAPI, por lo que puedes obtener una muy buena experiencia de desarrollo simplemente generando código para esas definiciones de OpenAPI que ya están disponibles para muchas APIs, por lo que no necesitas generar nuevas o crear nuevas bibliotecas o cualquier cosa para consumirlas. Entonces, no sé, creo que este fue un enfoque muy, muy interesante para probar y verificar si todo nos habría ayudado de alguna manera. Entonces, la pregunta para ti es, ¿escalamos el árbol? Entonces, ¿hey, escalamos el árbol? No sé. De todos modos, muchas gracias por ver. Prueba nuestra herramienta de código abierto en docs.platformatic.dev. Y no sé, muchas gracias. Y gracias a todos por recibirme en el S-Congreso. Gracias. Adiós. ¿Qué pasa, Matteo? ¿Cómo estás? Hola a todos. Hola. Me encanta tu voz, hombre. Tienes un estilo de presentación genial. Eso es increíble. ¿Por qué no pasamos a algunas preguntas? Tenemos algunas muy interesantes aquí. Estábamos viendo esto justo antes de comenzar y estábamos hablando de esta. ¿Qué deberías hacer si tienes problemas internos y tu equipo de front-end no puede confiar en tu equipo de back-end? Mencionaste en tu charla que no crees que deberías estar usando validación con Zod en el front-end

Validation in Production and TypeScript Conversion

Short description:

Realizar validación en producción puede ralentizar tu código y aumentar el tamaño del paquete. No se recomienda validar todas las respuestas en producción. Sin embargo, agregar un modo de desarrollo para identificar discrepancias en las respuestas puede ser útil. La capacidad de TypeScript para ejecutar código en el editor de desarrollo crea una experiencia única para los desarrolladores que me convenció de su valor.

o algo similar a Zod. ¿Qué deberías hacer en esas situaciones? Hay dos aspectos, vale. No, realmente no quieres hacer ese tipo de validación en producción. Principalmente porque hacer cualquier validación tiene, o tener cualquier biblioteca de validación en el front-end tiene más o menos dos efectos. Primero, ralentiza tu código. Este es el primero. Y el segundo, aumenta el tamaño del paquete. Por pequeña que sea, por pequeña que sea tu biblioteca, aún necesita ser analizada, evaluada. Cada vez que vas y llamas, estás validando esa respuesta y requiere bastante esfuerzo, vale. Entonces, para ser honesto, no es algo bueno para el uso en producción validar todas las respuestas.

Dicho esto, agregar algún tipo de modo de desarrollo o algo para poder señalar a tu equipo y al equipo del cliente y decir: mira, tu respuesta no es lo que dijiste que debería ser. Con un dedo pequeño, haces algo diferente. Has estado en esa posición, así que estoy bastante consciente, al igual que todos. Creo que agregaremos eso, de hecho, tal vez ya lo hicimos, pero en el momento en que grabé la charla. Así que está por venir, o si no está allí, está por venir pronto. Es útil, pero no tanto en ese sentido, porque si tienes este problema de que no quieres ejecutarlo en producción, ¿verdad? De lo contrario, pierdes muchas cosas. Sí. Quiero decir, tampoco necesariamente quieres que tu código de desarrollo sea diferente del código de producción. También está eso en la mezcla. Me encantó lo que dijiste al principio. Eres famoso, un converso reciente a TypeScript. Recuerdo, te he estado siguiendo en Twitter durante un tiempo, y hace unos años dijiste, sabes, TypeScript es malo, ¿por qué todos lo están haciendo? Y ahora estás aquí. Entonces, ¿qué pasó? ¿Qué cambió tu opinión? ¿Cuál es la historia de cómo te sentiste? OK. Me di cuenta de algo muy, muy interesante sobre TypeScript. TypeScript es código que se ejecuta en el editor de desarrollo. Y eso es probablemente la verdad más grande sobre TypeScript en la que puedes pensar. Y eso es lo que permite que TypeScript cree un cierto nivel de experiencia para el desarrollador que no es posible de otra manera. Y me encanta eso. OK, para ser honesto, esto es bastante fenomenal y asombroso. Así que esa es probablemente la razón. No he cambiado de opinión. Aunque te llevó un tiempo convencerte, ¿verdad? Quiero decir, no estabas de acuerdo de inmediato.

Initial Challenges with TypeScript

Short description:

Al principio, tuve una mala experiencia con la comunidad de TypeScript. Me criticaron por no escribir en TypeScript, lo cual era difícil y no se traducía directamente a JavaScript.

No, no lo estaba. Tuve un impacto muy negativo al principio con la comunidad de TypeScript, y básicamente me rechazaron por completo como persona. Recibí cientos de problemas diciéndome que escribiera esto en TypeScript, y realmente no quieres que nadie venga a tu casa y te diga que cambies la pintura. O que cambies los cimientos también. Quiero decir, eso es un gran problema. Cambiar los cimientos, ¿de acuerdo? Y en algunos casos, ni siquiera es posible. Como cuando esto sucedió, TypeScript no era ni siquiera una traducción 1 a 1 con JavaScript, y fue bastante malo, para ser honesto. Bueno, bienvenido de nuevo. Me alegra no haberte alienado por completo, pero estás aquí y eres parte de la comunidad. Una vez, creo que vi lo potente que es TypeScript. Creo que finalmente lanzaron todas las cosas que amo, que eran necesarias para hacer buenos tipos. Creo que en TypeScript, creo que tal vez el primer bloque fue en la versión 2.8. Luego, la segunda parte fue mucho más reciente, tal vez algo en la línea del árbol o algo así. Luego lanzamos un sistema de tipos fenomenal para Fastify. Fastify tiene la capacidad de escribir tus rutas, tanto con tipos, como en, um, uh, uh, uh, ¿documentos de Jazz o? No, no, no. Puedes usar Zod o Typebox. No sé si usas Typebox, yo no, todos hablan de eso, pero Typebox tiene muchas más descargas que eso. Es increíble. De acuerdo. Lo siento. Tiene un orden de magnitud más, pero todos están tan emocionados con Zod y esta cosa se usa. También puedes usar eso con Fastify, ¿verdad? Como. Sí, puedes usar ambos, así que puedes configurarlo para que puedas escribir tus rutas y especificar tus parámetros de entrada o salida usando, ya sea Zod o Typebox, y todo está completamente tipado de ida y vuelta. Y una vez. Y ver ese tipo de cosas te llevó a sentirte. Sí, sí. Esta es una experiencia de usuario increíble. Así que echemos un vistazo porque ha eliminado una de las mayores fuentes de fricción en este tipo de desarrollo, que es. Entonces, creo que Mateo, lo siento, tenemos que, um, detenerte ahí, pero creo que tenemos que pasar al siguiente ponente, pero muchas gracias Mateo. Si tienes preguntas sobre cualquier cosa, por favor envíalas. No puedo responder en Slido. Así que por favor. Sí, vamos a tener un chat especial para asegurarnos de que podamos enviar preguntas a Así que muchas gracias, Mateo. Gracias por tu tiempo. A continuación, tendremos a Jake Bailey. Nos vemos, amigo.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

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 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.
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. 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.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced