Historias y Estrategias de la Conversión a TypeScript

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

TypeScript es genial, pero migrar una aplicación existente a él puede ser un dolor de cabeza. Codecademy tomó múltiples aplicaciones React existentes y las convirtió a TypeScript. Cubriremos cómo hacer que ese tipo de conversiones sean exitosas desde puntos de vista tanto culturales como técnicos.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

Josh Goldberg es un desarrollador de front-end que ha trabajado en el equipo de plataforma web en Code Academy y anteriormente en Microsoft. Tiene experiencia en la conversión de JavaScript a TypeScript y ha desarrollado habilidades en compartir conocimiento técnico dentro de equipos de desarrollo.

TypeScript es un lenguaje de programación que extiende JavaScript añadiendo tipos estáticos. Code Academy decidió adoptarlo para mejorar la estabilidad de su aplicación de front-end, reducir errores y bloqueos en el sitio, y facilitar el manejo de una base de código grande y compleja.

El equipo se preparó mediante la realización de presentaciones internas para compartir conocimientos y familiarizar a todos con TypeScript. Se identificaron expertos y animadores dentro del equipo que ayudaron a propagar el entusiasmo y la información técnica necesaria para la transición.

La estrategia incluyó empezar con cambios mínimos, convertir algunos archivos esenciales para asegurarse de que la infraestructura era compatible y luego adoptar una estrategia de solicitudes de extracción dedicadas para áreas específicas, priorizando la facilidad de adopción sobre la rapidez.

Algunas de las principales lecciones incluyeron la importancia de automatizar la conversión tanto como sea posible, preparar guías de estilo y FAQs para resolver dudas comunes, y la necesidad de separar los cambios significativos de código de los cambios de conversión para facilitar las revisiones y la adopción.

Josh Goldberg recomienda el sitio web TypeScriptland.org por su excelente documentación y el curso de Code Academy sobre TypeScript. También menciona guías específicas para integrar TypeScript con herramientas populares de desarrollo como Babel y webpack.

Josh Goldberg
Josh Goldberg
20 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta Charla discute el proceso de conversión a TypeScript en CodeCademy. Se enfatiza la importancia de fomentar la adopción y el intercambio de conocimientos dentro del equipo. La Charla también destaca la integración perfecta de TypeScript en la infraestructura y el sistema de construcción existentes. La estrategia para la conversión a TypeScript involucró el uso de solicitudes de extracción dedicadas y herramientas automatizadas. El orador comparte consejos sobre la automatización de cambios, la configuración de una guía de estilo y la celebración de victorias. También se mencionan recursos para aprender TypeScript.

1. Introduction to Converting to TypeScript

Short description:

Hola, y bienvenidos a historias y estrategias de la conversión a TypeScript conmigo, Josh Goldberg. Para empezar, hola, soy de Upstate New York. Soy un desarrollador de front-end en el equipo de plataforma web en Code Academy, anteriormente Microsoft, y soy un papá de gatos. Comenzando, ¿dónde estaba CodeCademy antes de TypeScript? Retrocedamos hasta principios de 2019, una época más sencilla. Teníamos una aplicación principal de front-end, que en ese momento consistía en alrededor de 2,000 archivos de React y Redux, algunos archivos más en un sistema de diseño separado, que en sí mismo se convirtió a TypeScript como prueba de concepto, y la mayoría de los miembros del equipo solo habían oído vagamente hablar de TypeScript.

Hola, y bienvenidos a historias y estrategias de la conversión a TypeScript conmigo, Josh Goldberg.

Para empezar, hola, soy de Upstate New York.

Soy un desarrollador de front-end en el equipo de plataforma web en Code Academy, anteriormente Microsoft,

y soy un papá de gatos.

Mi esposa y yo tenemos algunos gatos.

Son muy lindos.

Todo el contenido de esta presentación está disponible en mi sitio web bajo el enlace de las diapositivas en esta charla en joshuakgoldberg.com.

Esta presentación incluye varias imágenes animadas en bucle.

Si te distraen, te recomendaría verlas en PowerPoint, que te permite pausarlas.

En cuanto a la agenda, primero vamos a hablar sobre Code Academy en 2019 antes de dar el salto a TypeScript, cómo tomamos esa decisión de pasar a TypeScript, algunas de las técnicas que utilizamos para compartir conocimientos en el equipo, los detalles técnicos de lo que hicimos para hacer ese cambio, y luego algunas de las lecciones que aprendimos al final del proceso, cosas que tal vez puedas utilizar en tus conversiones, espero. Buen material.

Comenzando, ¿dónde estaba CodeCademy antes de TypeScript?

Retrocedamos hasta principios de 2019, una época más sencilla.

Teníamos una aplicación principal de front-end, que en ese momento consistía en alrededor de 2,000 archivos de React y Redux, algunos archivos más en un sistema de diseño separado, que en sí mismo se convirtió a TypeScript como prueba de concepto, y la mayoría de los miembros del equipo solo habían oído vagamente hablar de TypeScript.

No había un gran tema o punto de conocimiento en el equipo.

El equipo en sí era bastante pequeño.

Eran solo alrededor de 20, tal vez 30 ingenieros como máximo.

La mayoría de las personas realmente no tenían experiencia con TypeScript y, como en cualquier equipo de ingeniería, había trabajo en curso en torno a características y correcciones de errores.

Entonces, ¿cómo lo hicimos?

¿Cómo hicimos ese cambio a TypeScript?

Primero, tomamos la decisión de que queríamos hacerlo en primer lugar, y cuando hay voluntad, hay una manera, pero tiene que haber voluntad.

Cualquier cambio arquitectónico debe contar con el apoyo informado de sus constituyentes.

Creo que mucha gente, especialmente aquellos que son nuevos en un equipo, cometen el error de tratar de sacar conclusiones de inmediato y empujar una agenda, enviar propuestas, lo cual muchas veces es un error hacerlo de inmediato.

Es una buena idea absorber las experiencias de ser un desarrollador en el equipo, hablar con la gente, tener una idea de cuáles son los problemas reales, y luego utilizar eso para informar tus decisiones sobre qué impulsar y cómo.

No me malinterpretes.

No estoy tratando de menospreciar el hecho de entrar en un equipo con una perspectiva fresca e intentar hacer que la gente entienda y escuche esa perspectiva.

Eso es genial.

Eso es encomiable.

Los equipos definitivamente deberían estar abiertos a que llegues con ideas frescas, pero esas ideas frescas y perspectivas tienen muchas más posibilidades de tener éxito si las validas con quienes te rodean, si puedes convencer a las personas de su validez.

Así que no seas un malcriado.

Definitivamente habla con la gente antes de intentar presionarlos para que hagan cosas.

Si realmente quieres presionar a la gente para que haga cosas, te recomiendo encarecidamente que crees algún tipo de ambiente emocionante para ello.

Si hay algún cambio que quieras hacer, como TypeScript, quieres que la gente lo sienta.

Deberían estar emocionados en sus huesos.

2. Fomentando la adopción de TypeScript

Short description:

Esto es increíble. Esto va a hacer mi vida más feliz y mejor, el código va a funcionar, va a ser increíble, quiero hacerlo. Esa es la sensación que quieres transmitir con algunas de las decisiones más importantes que quieres impulsar en el equipo. Parte de la forma en que lo hicimos fue alentar a las personas a pensar en cómo TypeScript ayuda a sus objetivos existentes, siempre es una buena idea.

Esto es increíble. Esto va a hacer mi vida más feliz y mejor, el código va a funcionar, va a ser increíble, quiero hacerlo. Esa es la sensación que quieres transmitir con algunas de las decisiones más importantes que quieres impulsar en el equipo.

Parte de la forma en que lo hicimos fue alentar a las personas a pensar en cómo TypeScript ayuda a sus objetivos existentes, siempre es una buena idea. Mi imagen favorita de la fase de evangelización de nuestra versión de TypeScript al comienzo fue anunciarlo como parte del embudo de adquisición de errores, como lo llamamos, o el antifunnel. No dibujado a escala ya que no hay una escala confiable aquí. Ninguna parte de esto, ya sea la revisión de código o lo que sea, puede prevenir realmente todos los errores, pero juntos pueden ayudar a reducir los errores y los bloqueos en los sitios. Eso fue una gran parte del plan del equipo a principios de 2019, algo en lo que queríamos mejorar, la estabilidad, no tener errores y peculiaridades molestas. TypeScript es una de las características principales de TypeScript, y te ayuda a encontrar errores temprano.

3. Ramping up the Team and Knowledge Sharing

Short description:

Una vez que decidimos hacerlo, necesitamos preparar al equipo. Identificamos dos arquetipos: expertos en el área y animadores. Los expertos en el área pueden introducir las mejores prácticas, explicar TypeScript y salvar al equipo de errores obvios. Los animadores, aunque tengan menos experiencia, pueden actuar como conejillos de indias y ayudar a difundir la nueva tecnología. Se recomienda tener al menos uno o dos animadores por área del equipo y al menos dos expertos en el área para validación e intercambio de ideas.

Entonces, una vez que decidimos hacerlo, necesitamos preparar al equipo. Compartir conocimientos, como ellos lo llaman. Esto fue especialmente valioso antes de tomar la decisión, donde queríamos que las personas entendieran lo que significaba para que pudieran contribuir de manera significativa a la conversación. Identificamos aproximadamente dos arquetipos de personas en el equipo. En primer lugar, teníamos a los expertos en el área, alguien como yo que ya está muy emocionado y familiarizado con TypeScript. Puedo decirlo. Son el tipo de persona que puedes usar para informar al equipo sobre la tecnología, introducir mejores prácticas, explicarla a los demás, establecer los materiales de aprendizaje adecuados. Son la persona que puede salvar al equipo de sí mismos, evitando caer en los errores obvios que tú conoces por haberlo hecho antes. También son útiles y muy valiosos en el equipo los animadores, personas que pueden no tener tanta experiencia con, digamos, TypeScript, pero que aún están muy emocionados y quieren impulsarlo y están de acuerdo con ello. Estas son las personas que pueden actuar como conejillos de indias, que lo probarán, tus primeros adoptantes o probadores beta, como los llaman. Pueden ayudar a difundirlo entre el equipo de manera mucho más efectiva que tú, porque hay muchos de ellos, a menudo, si la decisión es emocionante y nueva. Así que recomiendo tratar de tener al menos uno o dos animadores por área del equipo para que puedan difundir la alegría de la nueva cosa entre el área del equipo. Al menos en Codecademy y muchas otras empresas que he visto, los equipos de producto tienden a hablar mucho entre sí. Así que si puedes tener al menos una persona en esa mezcla, eso es muy útil para introducir una nueva tecnología. Para los expertos en el área, es útil tener al menos dos, porque si solo tienes uno, no tienen un compañero que realmente pueda validar lo que están haciendo, al menos desde la experiencia previa. Así que es útil tener al menos dos que puedan intercambiar ideas entre ellos.

4. Knowledge Sharing and Code Changes

Short description:

Parte del intercambio de conocimientos para nosotros fue a través de presentaciones internas, incluyendo charlas informales, análisis estático en JavaScript y charlas relámpago. Las sesiones de emparejamiento con miembros del equipo enfocados en el frontend también fueron valiosas. Mantener los cambios de código mínimos y comenzar con la conversión de algunos archivos aseguró una transición sin problemas sin interrumpir al equipo.

Parte del intercambio de conocimientos para nosotros, una vez que identificamos a los responsables del área y a los animadores, fueron las presentaciones internas porque nadie hace nada hasta que haya una charla que explique la idea general, el espíritu del movimiento del equipo hacia ella. Realizamos dos charlas informales, que tu equipo podría llamar charlas de tiza o charlas de almuerzo o algo similar presentaciones.

La primera fue el análisis estático en Javascript. Fue una introducción general al concepto de analizar el archivo sin ejecutar y descubrir qué está mal o bien en él. Y honestamente, ni siquiera hablamos tanto de TypeScript. Fue principalmente sobre las herramientas existentes que ya estábamos usando para que las personas se pusieran en el estado mental correcto, principalmente las más tempranas.

Después de eso, tuvimos la charla realmente emocionante, cuando estaba feliz por TypeScript, que fue específicamente sobre qué es TypeScript y cómo se verían las características que usaríamos. También participamos en las charlas relámpago existentes del equipo, que eran una serie de unas pocas personas hablando cada semana, alrededor de cinco minutos, sobre cualquier tema aleatorio. Estas fueron particularmente útiles para los temas más esotéricos de TypeScript que podrían ser interesantes o lindos pero no del todo útiles para la mayoría de las personas que intentan decidir si usarlo o adoptarlo. Las presentaciones son realmente útiles porque las personas pueden verlas después y repasar el contenido.

Las interacciones individuales más valiosas, creo, fueron emparejarse con personas porque nadie realmente aprende algo hasta que se ve obligado a hacerlo, al menos en mi experiencia. Y la generalización fue útil. Al menos para mí, si no he escrito un lenguaje o no he usado un marco de trabajo, no realmente lo entiendo hasta que lo hago. Así que programé al menos una sesión de emparejamiento con cada miembro del equipo enfocado en el frontend, que en ese momento eran alrededor de una docena, un poco más. En estas sesiones, nos emparejábamos, uno codificaba en TypeScript y el otro supervisaba. No fue escalable. Intentaría hacerlo ahora que el equipo es de más de 50-60 personas. Eso sería realmente doloroso. Pero en ese momento, fue útil y creo que fue una de las formas más importantes y relevantes de incorporar a las personas a TypeScript. Lo recomiendo encarecidamente, especialmente si puedes ampliarlo con más responsables del área.

En cuanto a los detalles técnicos, los cambios de código literales que hicimos, los mantuvimos al mínimo posible. Y esta es una estrategia que recomendaría encarecidamente para cualquier conversión a TypeScript. No quieres empezar con una solicitud de extracción de varios miles de archivos que convierta todo bajo el sol. Eso es muy fácil de romper y muy difícil de ajustar para conflictos de fusión. Así que comenzamos con la conversión mínima de las integraciones de infraestructura con solo unos pocos archivos, convirtiéndolos a TS o TSX, solo para asegurarnos de que funcionara. Esto fue bueno por varias razones. En primer lugar, la solicitud de extracción inicial no interrumpió al equipo en absoluto. No tuvimos que detener las implementaciones ni nada para avanzar. Tampoco cambiamos mucho a las personas con eso. Nadie se vio afectado por ello.

5. Introducing TypeScript into the Infrastructure

Short description:

Pudimos introducir TypeScript sin problemas en nuestra infraestructura, ya que la mayoría de las herramientas que utilizamos ya tenían soporte incorporado o integración fácil. Babel, nuestro ejecutor de pruebas y constructor de producción, tenía un conjunto de ajustes de TypeScript que funcionaba como magia. ESLint, con el que estoy familiarizado, también funcionaba muy bien con TypeScript. Y la mejor parte fue que Prettier admitía TypeScript de forma nativa sin necesidad de ninguna configuración.

Pudimos esperar para presentar TypeScript a las personas hasta que fuera el momento adecuado, hasta que pudiéramos emparejarnos con ellos o hasta que ya se sintieran más cómodos con las ideas. Y, sinceramente, la infraestructura no fue un cambio tan grande en esta solicitud de extracción. Prácticamente todo lo que usamos ya tenía una inclusión básica de TypeScript, ya sea incorporada o algo que se puede obtener fácilmente en línea. Nuestro ejecutor de pruebas y nuestro constructor de producción, Justin Roepack, respectivamente, tenían dependencia de Babel para compilar el código, y Babel tiene un conjunto de ajustes de TypeScript realmente bueno, el conjunto de ajustes de Babel para TypeScript. Así que simplemente lo usamos y funcionó como por arte de magia. ESLint tiene TypeScript ESLint, un proyecto al que a veces contribuyo, por lo que estoy bastante familiarizado con él, y también funcionó muy bien. Las ejecuciones de ESLint nos llevan un poco más de tiempo porque incluimos el verificador de tipos, y eso está bien. Aún así, todo funciona. Curiosamente, Prettier ni siquiera tiene un paso de configuración que necesitáramos usar. Simplemente admite TypeScript automáticamente de forma nativa. Esa fue mi parte favorita. No tuvimos que hacer nada al respecto. Fue genial.

6. Introducing TypeScript into the Build System

Short description:

Introdujimos TypeScript en el sistema de compilación con la facilidad de adopción en mente. Solo usamos TypeScript como un verificador de sintaxis y tiempo de compilación, sin interrumpir a los ingenieros con código heredado. Si bien inicialmente no habilitamos la configuración 'no implicit any', más tarde convertimos los archivos en 'null implicit any'. Sin embargo, habilitamos las comprobaciones estrictas de nulos desde el principio.

Una vez que introdujimos TypeScript en el sistema de compilación, priorizamos la facilidad de adopción en lugar de hacer todo de forma rápida y repentina en TypeScript. Así que tratamos de no ser demasiado disruptivos para las personas. Exclusivamente usamos TypeScript como una sintaxis y un verificador de tiempo de compilación. No lo utilizamos para verificar código JavaScript o cosas existentes que no eran TypeScript. No queríamos interrumpir a los ingenieros con mensajes sobre código heredado que aún no estaba destinado a ser TypeScript. Por lo tanto, no había necesidad de verificar JS, como se llama la opción del compilador.

Tampoco activamos la configuración del compilador 'no implicit any', que es muy útil, desafortunadamente. Es difícil en una base de código mixta de TypeScript y JavaScript. Si un archivo importa desde un archivo JavaScript y quieres convertirlo a TypeScript, entonces a veces tienes que convertir todas sus dependencias para configurar correctamente esos tipos. Y eso es simplemente molesto. Terminamos utilizando un proceso similar más adelante para convertir gradualmente los archivos en 'null implicit any'.

Por otro lado, sí pudimos habilitar fácilmente las comprobaciones estrictas de nulos desde el principio. Un concepto muy simple, no considerar nulo y indefinido como asignables a otros tipos. Y fue muy útil. Así que sí, lo obtuvimos desde el principio. Maravilloso.

7. Converting to TypeScript Strategy and Tools

Short description:

Utilizamos solicitudes de extracción dedicadas para convertir a TypeScript, centrándonos en áreas específicas e involucrando a los ingenieros según la propiedad. Estas solicitudes de extracción brindaron una gran oportunidad para aprender y compartir conocimientos. También desarrollé un script para verificar el lenguaje de los commits antiguos, lo cual nos ayudó a rastrear el progreso de la conversión. La conversión tomó 259 días, priorizando la comodidad sobre la velocidad. Una de mis herramientas favoritas, Typestep, aplica automáticamente las conversiones en los archivos, lo que hace que el proceso sea más eficiente. Es de código abierto y puede generar representaciones de TypeScript de los tipos de propiedades.

A medida que avanzábamos en el tiempo, adoptamos una estrategia de solicitudes de extracción dedicadas, en su mayor parte, para convertir a TypeScript. Ocasionalmente, un miembro del equipo se emocionaba y convertía algo a TypeScript como parte de una solicitud de extracción existente, pero en su mayor parte, simplemente convertíamos áreas a TypeScript. Esto nos permitió enfocarnos en áreas específicas y centrar esas solicitudes de extracción solo en TypeScript, lo que hacía un poco más claro cuáles eran los cambios. En la mayoría de los casos, o muchos casos, no hubo cambios reales en tiempo de ejecución. Y nos ayudó a comprender qué ingenieros involucrar según las áreas de propiedad.

Esto también fue una gran oportunidad de aprendizaje para la mayoría del equipo. En cada una de estas solicitudes de extracción, explicamos todas las nuevas piezas potencialmente confusas de sintaxis con comentarios en la solicitud de extracción, agregamos un tipo aquí porque, etc. Luego, cuando las personas revisaban las solicitudes de extracción, casi instintivamente tenían que leer estos comentarios, lo cual fue bastante agradable. Así que recomiendo encarecidamente las solicitudes de extracción dedicadas como una forma de ayudar a compartir conocimientos después de la colaboración.

Más adelante, escribí un pequeño script que ejecutaba el comando Git checkout en cada uno de nuestros commits antiguos y verificaba los archivos JS versus los archivos TS para ver cuál era el lenguaje de cada uno. Como puedes ver, con el tiempo, imprime el crecimiento porcentual, lo cual fue bastante ingenioso. Comenzamos la conversión el 2 de abril de 2019, al día siguiente de nuestro lanzamiento del 1 de abril, que fue un curso de código de leyes completamente funcional, que es un lenguaje de programación basado en el uso de Internet y gatos, uno de mis favoritos. La conversión nos llevó aproximadamente 259 días hasta el 17 de diciembre, lo cual está bien. Si hubiéramos querido, podríamos haber priorizado movernos más rápido, pero queríamos optimizar la velocidad. Lo siento, la lentitud, la comodidad sobre la velocidad, algo que recomiendo encarecidamente. No asumas que tienes que pasar a TypeScript de inmediato. Es probable que puedas convertir parte de tu base de código, áreas de alto valor, antes como una forma de prepararte para más adelante.

Mi parte técnica favorita fue Typestep, que es una herramienta que escribí que aplica automáticamente conversiones deducibles o evidentes en masa. Por ejemplo, si un componente de React declara sus prop types con el paquete properties, a veces puedes crear automáticamente un tipo o interfaz de TypeScript solo con mirar el archivo. Es una herramienta bastante involucrada. Aún está en una etapa temprana, tiene muchos errores, pero es de código abierto. Recomiendo encarecidamente echarle un vistazo si quieres usar algo similar para tus conversiones de tipos. Me llevó muchas horas escribirlo, pero nos está ahorrando mucho tiempo hasta el día de hoy para nuestras conversiones. Así que estoy bastante satisfecho con ello. Probablemente podría dar una charla completa, pero no tenemos el tiempo ni el enfoque para esta ocasión. Este es un ejemplo para reiterar, si usas prop types, podríamos leer tu archivo y escribir un script que analice el texto para comprender qué tipo de prop es, es una lista de props y para cada uno de ellos, cuál es el tipo. Y luego podrías imprimir de vuelta al archivo la representación de TypeScript de eso. Es un poco más complicado para los componentes que no declaran sus prop types propias. Tienes que usar el comprobador de tipos para encontrar todas las referencias al componente para ver qué tipos y nombres tienen todas las props proporcionadas en todas esas referencias, y luego combinar todo eso, que es algo que hace Typestat.

8. Automatización de cambios y configuración de guía de estilo

Short description:

Entonces, nuevamente, un poco más complicado, pero aún factible. Automatiza todo y cualquier cosa siempre que sea posible. Configura una guía de estilo y aprende preguntas preventivas. No conviertas y cambies al mismo tiempo. Los ingenieros de TypeScript tienen esta fobia de escribir la palabra any porque piensan que hace que el código sea menos bueno.

Entonces, nuevamente, un poco más complicado, pero aún factible. Así que piensa en los casos extremos y observa Typestat si estás interesado. De todos modos, aprendimos mucho y quedé muy satisfecho con el proceso. Así que me gustaría compartir eso contigo ahora, si está bien. Para empezar, automatiza todo y cualquier cosa siempre que sea posible. Ya sea una configuración realmente compleja como Typestat o simplemente un pequeño script de bash o Node que escribas para hacer el 70% del trabajo obvio. Nos apoyamos en esto para la gran mayoría de los cambios. Mis PR favoritas, las más fluidas, se generaron con Typestat para el 80 al 90% del trabajo, y luego las ajustamos a mano para que fueran correctas. Verificar dos veces. Quiero decir, ¿por qué hacer cosas cuando puedes escribir un script para hacerlo por ti? Además, solo por trabajar con ingenieros, recomiendo encarecidamente configurar una guía de estilo y aprender qué preguntas harían las personas de manera preventiva. Preguntas como, ¿deberías usar una interfaz o un tipo? ¿Cómo declaras las props de React? ¿Qué significa este error común y confuso? Eso se va a preguntar. Se preguntará una y otra vez y desde el principio, así que sé proactivo. Habla con las personas con anticipación y averigua qué es lo que realmente necesitas cubrir y que te preguntarán repetidamente. Una guía de estilo es una excelente manera de responder muchas de estas preguntas y tener una sección de preguntas frecuentes al final. Definitivamente aprendimos de la manera difícil y lo siento si eres un usuario de Code Academy en 2019 y rompimos este sitio o agregamos un error para ti. No conviertas y cambies al mismo tiempo. Cualquier PR importante que cambie toda un área de TypeScript es algo difícil de revisar y es especialmente difícil si también introduces cambios en tiempo de ejecución. Así que recomiendo encarecidamente mantenerlos separados. Si ves un cambio que realmente quieres hacer para TypeScript, simplemente anótalo, guárdalo para más tarde. Resiste la tentación. Sé compasivo incluso en tu revisión de código o para alguien que ahora tiene que pasar por tu PR y QA cambios además de tal vez aprender TypeScript. Eso es un gran desafío. Muchos ingenieros, especialmente en relación con TypeScript, no les gusta tomar atajos. No les gustan los atajos intelectuales. Debería decir. No les gusta hacer las cosas de manera incorrecta. Los ingenieros de TypeScript tienen esta fobia de escribir la palabra any porque piensan que eso hace que el código sea menos bueno. Tal vez solo tengas que hacer una conversión a any, como estábamos usando Redux, lo cual está bien. Redux por sí solo es un sistema hermoso y muy compatible con el sistema de tipos. Pero cuando tienes todas estas integraciones, como nosotros, acciones de Redux, doggos, thunks, se vuelve realmente difícil escribir los tipos.

9. Reflexiones Finales y Recursos

Short description:

Nos llevó meses de trabajo llegar a la misma versión de typings para Redux debido a las dependencias interconectadas. Aún convertimos gran parte de nuestro código de Redux en TypeScript. Celebra tus victorias y haz un gran evento al convertir a TypeScript. Visita TypeScriptland.org y CodeCademy.com para obtener recursos sobre TypeScript. Gracias por escuchar!

Nos llevó meses de trabajo en segundo plano llegar a la misma versión de typings para Redux debido a todas las extrañas dependencias interconectadas. Y aún convertimos gran parte de nuestro código de Redux en TypeScript porque simplemente no tenemos tiempo o interés en hacerlo al 100% correctamente. Así que simplemente convierte, está bien. La elección entre convertir y no convertir a TypeScript debería ser bastante clara, simplemente conviértelo y guárdalo para más tarde. Opiniones.

Por último, celebra tus victorias. Gastamos un poco del presupuesto de la oficina en esta tarta y fue algo divertido para el ánimo de, oh, hicimos algo genial. Convertimos a TypeScript. Terminamos. Y fue en diciembre. Ayuda a señalar al equipo cuando haces algo lindo y memorable al final. Recomiendo encarecidamente hacer un gran evento al respecto. Si el tren de la emoción, como podrías haberlo llamado, termina su viaje, celebra su llegada a la estación como una analogía. Irónicamente, creo que la tarta era de vainilla al final.

De todos modos, aquí tienes algunos recursos que podrían ser útiles para ti. El sitio web TypeScriptland.org. Un saludo a nuestro amigo, Orta, es realmente bueno. Tiene mucha documentación excelente, explica muchas cosas buenas sobre TypeScript. Puede ayudarte como nuevo implementador, usuario experimentado o convertidor. De hecho, terminamos escribiendo un curso sobre TypeScript, en el que ayudé como co-líder en la concepción, CodeCademy.com, aprende TypeScript. Lo recomiendo mucho, soy un gran fan. Y luego cada una de las integraciones que mencioné, la guía de Babelius Lynch para webpack tiene su propia guía para usar TypeScript porque es muy popular. Así que recomiendo encarecidamente visitar esos recursos. De todos modos, gracias por escucharme. He estado respondiendo preguntas en el chat a medida que surgen. Y siempre puedes enviarme un tweet o ver mi información de contacto en mi sitio, ambos son joshuakagleberg. Gracias. Que tengas un excelente resto de la conferencia y muchas gracias a los organizadores de la 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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.