¿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.
This talk has been presented at TypeScript Congress 2023, check out the latest edition of this Tech Conference.
FAQ
Matteo Collina es miembro del Comité de Dirección Técnica de Node.js y miembro de la Junta Directiva de la Fundación Open Source Open JS. Ha creado y mantenido numerosas bibliotecas de Node.js, con un uso significativo en la comunidad.
Fastify es un framework que Matteo Collina ayudó a desarrollar para construir APIs en Node.js. Ofrece la capacidad de generar documentación y definiciones de especificaciones OpenAPI de manera rápida y eficiente para las rutas definidas.
Antes de 2022, Matteo Collina casi nunca había usado TypeScript, pero comenzó a usarlo ese año cuando inició una nueva empresa, lo que le llevó a profundizar en el uso de TypeScript para el desarrollo empresarial.
tRPC es una biblioteca que facilita la creación de llamadas RPC desde el cliente al servidor de manera segura en cuanto a tipos. Su desventaja principal es el acoplamiento de tipos que introduce entre el código del frontend y el backend.
El objetivo de Matteo Collina es ayudar a los desarrolladores a eliminar el trabajo pesado indiferenciado en la construcción de aplicaciones JS, permitiendo un desarrollo más rápido y eficiente sin un acoplamiento estrecho entre el servidor y el cliente.
Matteo Collina propuso utilizar el estándar OpenAPI para definir las rutas y generar automáticamente un cliente que pueda consumir estas APIs de manera eficiente y completamente tipada, sin validaciones de datos en tiempo de ejecución.
Matteo Collina recomendó la biblioteca Cold Block Writer para la generación de código dinámico, destacando su facilidad de uso y la capacidad de generar código homomórfico que facilita la identificación y corrección de errores.
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.
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.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Today's Talk focuses on React's best types and JSX. It covers the types of JSX and React components, including React.fc and React.reactnode. The discussion also explores JSX intrinsic elements and react.component props, highlighting their differences and use cases. The Talk concludes with insights on using React.componentType and passing components, as well as utilizing the react.element ref type for external libraries like React-Select.
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
WebAssembly enables optimizing JavaScript performance for different environments by deploying the JavaScript engine as a portable WebAssembly module. By making JavaScript on WebAssembly fast, instances can be created for each request, reducing latency and security risks. Initialization and runtime phases can be improved with tools like Wiser and snapshotting, resulting in faster startup times. Optimizing JavaScript performance in WebAssembly can be achieved through techniques like ahead-of-time compilation and inline caching. WebAssembly usage is growing outside the web, offering benefits like isolation and portability. Build sizes and snapshotting in WebAssembly depend on the application, and more information can be found on the Mozilla Hacks website and Bike Reliance site.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
TypeScript no es solo tipos e interfaces. Únete a esta masterclass para dominar características más avanzadas de TypeScript que harán tu código a prueba de balas. Cubriremos tipos condicionales y notación de inferencia, cadenas de plantillas y cómo mapear sobre tipos de unión y propiedades de objetos/arrays. Cada tema se demostrará en una aplicación de muestra que se escribió con tipos básicos o sin tipos en absoluto y juntos mejoraremos el código para que te familiarices más con cada característica y puedas llevar este nuevo conocimiento directamente a tus proyectos. Aprenderás:- - ¿Qué son los tipos condicionales y la notación de inferencia?- ¿Qué son las cadenas de plantillas?- Cómo mapear sobre tipos de unión y propiedades de objetos/arrays.
TypeScript tiene un sistema de tipos poderoso con todo tipo de características sofisticadas para representar estados de JavaScript salvajes y extravagantes. Pero la sintaxis para hacerlo no siempre es sencilla, y los mensajes de error no siempre son precisos al decirte qué está mal. Vamos a profundizar en cómo funcionan muchas de las características más poderosas de TypeScript, qué tipos de problemas del mundo real resuelven, y cómo dominar el sistema de tipos para que puedas escribir código TypeScript verdaderamente excelente.
¿Eres un desarrollador de React tratando de obtener los máximos beneficios de TypeScript? Entonces esta es la masterclass para ti.En esta masterclass interactiva, comenzaremos desde lo básico y examinaremos los pros y contras de las diferentes formas en que puedes declarar componentes de React usando TypeScript. Después de eso, pasaremos a conceptos más avanzados donde iremos más allá de la configuración estricta de TypeScript. Aprenderás cuándo usar tipos como any, unknown y never. Exploraremos el uso de predicados de tipo, guardias y comprobación exhaustiva. Aprenderás sobre los tipos mapeados incorporados, así como cómo crear tus propias utilidades de mapa de tipo nuevo. Y comenzaremos a programar en el sistema de tipos de TypeScript usando tipos condicionales e inferencia de tipos.
Durante este masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debe conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final del masterclass, los participantes ganarán confianza en su capacidad para escribir código JavaScript de alta calidad que perdure en el tiempo. Puntos Cubiertos: 1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso Cómo Ayudará a los Desarrolladores: - Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento profesional y las oportunidades de avance en la industria del software
I'll introduce the audience to a concept where they can have end-to-end type systems that helps ensure typesafety across the teams Such a system not only improves communication between teams but also helps teams collaborate effectively and ship way faster than they used to before. By having a custom type system, teams can also identify the errors and modify the API contracts on their IDE, which contributes to a better Developer Experience. The workshop would primarily leverage TS to showcase the concept and use tools like OpenAPI to generate the typesystem on the client side.
Comments