Video Summary and Transcription
Bienvenido a TypeScript más React es igual a amor. Las características de TypeScript pueden prevenir errores en las aplicaciones de React. TypeScript brinda confianza para eliminar props no utilizados. TypeScript garantiza definiciones precisas de props y previene la pereza. TypeScript proporciona seguridad de tipos y patrones avanzados para una mejor experiencia de desarrollo. TypeScript es una buena opción para proyectos, especialmente los más grandes.
1. Introducción a TypeScript y React
Bienvenidos a TypeScript más React es igual a amor. Mostraré las características de TypeScript que pueden prevenir errores en nuestras aplicaciones de React. Visiten BenMVP.com para ver las diapositivas. Mi nombre es Ben Alegbedo, soy cristiano, esposo y padre. Vivo en el área de la Bahía de San Francisco y trabajo como ingeniero principal de front-end en Stitch Fix. Sumergámonos en este negocio de React más TypeScript.
¡Vamos a echar un vistazo! ¡Hola! Bienvenidos. En primer lugar, quiero desear un feliz quinto aniversario a React Summit! ¡Feliz cumpleaños! Y bienvenidos a todos ustedes a TypeScript más React es igual a amor. Saben, en realidad, me hubiera gustado usar un emoji de fuego en lugar de porque así de increíble, creo, es la asociación entre TypeScript y React. Pero me quedé con el emoji de corazón.
Así que quiero pasar nuestro tiempo mostrando las características de TypeScript que pueden prevenir errores en nuestras aplicaciones de React. ¿De acuerdo? Así que asumo que ya han desarrollado en React antes, pero saben poco o nada de TypeScript. Incluso si saben mucho de TypeScript, obtendrán mucho de esto. Pero para aquellos que no conocen TypeScript, explicaré los conceptos a medida que avanzamos. Y solo para que lo sepan, estas diapositivas ya están en línea. Si visitan mi sitio, BenMVP.com, encontrarán un enlace allí. O pueden seguir el enlace de Bitly que está en la parte inferior.
Muy bien. Permítanme presentarme formalmente, mi nombre es Ben Alegbedo. Soy cristiano, esposo y padre. Muy rápido, esta es mi familia. Esta es mi esposa, Rashida. Nos casamos hace 10 años, en septiembre pasado. Esta es nuestra hija mayor, Symone. Tiene seis años y medio. Nuestra hija del medio, Avery, que cumplió cuatro años el mes pasado también. Y en la parte inferior está nuestro hijo. Él es Asher. Tiene poco más de un año y medio, y todavía estamos tratando de hacerlo sonreír en las fotos. Todavía estamos trabajando en eso. Vivimos en el área de la Bahía de San Francisco, en una ciudad llamada Pittsburgh, California. Así que no es Pittsburgh, Pensilvania, es Pittsburgh, California sin la H. Soy ingeniero principal de front-end en Stitch Fix, y también soy experto en desarrollo de Google y Microsoft MVP, ambos en tecnologías web.
Muy bien. Suficiente sobre mí. Sumergámonos en este negocio de react más TypeScript.
2. Componentes y Props de React en TypeScript
Un componente de React es simplemente una función que recibe props y devuelve JSX. Puedes usar una interfaz para definir las props, y el tipo de la interfaz se convierte en el tipo del argumento props que se pasa a los componentes de la aplicación. Las props no se pueden utilizar sin una definición, lo que ayuda a detectar errores.
Entonces, una cosa que quiero dejar clara antes de comenzar, es que un componente de react es simplemente una función. No hay nada realmente especial al respecto. Simplemente recibe props y devuelve JSX, por lo que puede tratarse y escribirse como cualquier otra función de TypeScript.
Para empezar, puedes usar una interfaz para definir las props, como ves aquí, y el tipo de la interfaz se convierte en el tipo del argumento props que se pasa a los componentes de la aplicación. Puedes darle cualquier nombre a la interfaz. Aquí elegí `app props` solo como ejemplo, pero suelo usar simplemente `props`. Y lo verás en las diapositivas siguientes a medida que avanzamos.
Bien, entonces el primer beneficio, vamos directo al grano con TypeScript. Las props no se pueden utilizar dentro de un componente sin una definición. ¿Cuántas veces has tenido props en un componente que se usan sin una definición de tipo de prop? Exacto. Y en este caso, estamos intentando usar props llamadas `loading` sin definirlas en las props anteriores. Y eso se convierte en un error. Hay varias reglas para tratar de detectar este tipo de cosas, pero pueden ser limitadas.
3. TypeScript y Props no utilizados
TypeScript te brinda la confianza para eliminar props no utilizados porque no lo habría permitido en primer lugar. Los mensajes de error pueden parecer crípticos al principio, pero te familiarizarás más con ellos con el tiempo.
De hecho, están limitados en cómo llamas a la prop. Entonces, de manera similar, cuando no puedes pasar una prop si no se ha definido. Correcto. Aquí estamos tratando de pasar counts, pero count no estaba en la interfaz para app props. Entonces, ¿cuántas veces has visto que se pasa una prop a un componente y no está en los tipos de prop y parece que no se usa en el código, pero tienes miedo de eliminarla porque simplemente no estás seguro? Bueno, TypeScript te brinda la confianza de que puedes eliminarla porque no lo habría permitido en primer lugar. Entonces, este mensaje de error en la parte inferior puede parecer un poco críptico. Para ser honesto, la propiedad count no existe en el tipo de atributos intrínsecos y app props. Pero a medida que te encuentres con ellos más y más, te familiarizarás y te acostumbrarás un poco más a ellos.
4. React Prop Types y TypeScript
Los tipos de propiedades de React son opcionales de forma predeterminada. Las interfaces de script son requeridas de forma predeterminada. TypeScript se quejará si te olvidas de algo o simplemente confundes una prop. TypeScript evita la pereza y garantiza definiciones precisas de propiedades. TypeScript es beneficioso en las refactorizaciones.
De acuerdo, el siguiente. Entonces, los tipos de propiedades de React son opcionales de forma predeterminada cuando los enumeras. Así que veo muchos ejemplos donde se definen los tipos de propiedades, en realidad, pero ninguno de ellos está marcado como requerido. Pero si miras el código, las propiedades son definitivamente requeridas, como cuando se llama a .map en un array y cosas así. Estos son errores esperando a suceder. Las interfaces de script son requeridas de forma predeterminada, por lo que sin hacer nada especial, tienes la garantía de que los valores siempre existirán. Eso es muy bueno. Entonces, si llamo a este componente sin incluir la propiedad requerida count en este caso, me lo advertirá. Y nuevamente, no se compilará. Por lo tanto, puedes usar el signo de interrogación para indicar que una propiedad es opcional, lo que significa que su valor es undefined cuando no se pasa. Entonces, ahora si omito la propiedad count al renderizar app, en este ejemplo, no hay errores porque se establecerá por defecto en dos.
De acuerdo, si cambias el nombre de una propiedad, todos los lugares donde se usa también deben cambiarse. Digamos que esta propiedad aquí resaltada se llamaba originalmente names, pero la cambié a players dentro del componente. Entonces vas y buscas y reemplazas para solucionar todos los problemas. Pero, ¿los encontraste todos? ¿Cómo puedes estar seguro al 100 por ciento? ¿Y si alguien estaba haciendo algo loco y no coincidía con tu expresión regular? Bueno, TypeScript se quejará si te olvidas de algo. Y en realidad, un derivado de esto es cuando simplemente confundes una propiedad. TS también se quejará de inmediato.
De acuerdo, número cuatro, parece que es mucho trabajo definir una forma anidada profundamente. Correcto. Incluso con las reglas de ES lit, encontramos formas de hacer trampa. No hay nada que obligue a los tipos de propiedades a ser 100 por ciento precisos. Bueno, TypeScript ahora se interpondrá en tu camino y te impedirá ser perezoso. Nos impide ser perezosos. Déjame incluirme a mí también. Pero también te está salvando porque tienes que definir exactamente lo que está disponible. No puedes acceder a propiedades de la propiedad de usuario a menos que definas exactamente cuáles son. Entonces, si decidimos en la interfaz de dirección cambiar is primary a solo primary, obtendremos errores de TypeScript en toda la aplicación y el componente de la aplicación hasta que los solucionemos. Entonces, una vez más, TypeScript es muy beneficioso en las refactorizaciones.
De acuerdo, el siguiente y este en realidad es probablemente mi favorito. Así que con los tipos de propiedades, todo lo que obtienes son tipos de propiedades que funcionan para una función.
5. TypeScript y Errores de Funciones
En TypeScript, debes definir tanto los argumentos como el valor de retorno de un componente. Si realizas cambios, TypeScript mostrará un error a menos que corrijas todos los lugares afectados. Las funciones a menudo se llaman como resultado de la interacción del usuario, lo que facilita pasar por alto los errores durante las pruebas manuales.
Correcto. No hay nada que indique a un usuario del componente qué parámetros pasará cuando se llame o si espera que se devuelva algo. Correcto. Todo lo que obtienes es eso. Bueno, ahora en TypeScript, debes definir tanto los argumentos como el valor de retorno. Y una vez más, si decidimos agregar un segundo parámetro a on change, por ejemplo, o cambiar los tipos de los parámetros, TypeScript mostrará un error a menos que corrijamos todos esos lugares. Esto sucede todo el tiempo. ¿Cuántas veces has olvidado cambiar un controlador funcional en algunos lugares? Correcto. Y lo que sucede con las funciones es que generalmente se llaman como resultado de la interacción del usuario, lo que significa que es menos probable que encuentres este error durante las pruebas manuales. Ahora estás confiando en tu excelente cobertura de pruebas para detectar estos errores.
6. Patrón Avanzado: Props Dependientes
A veces tienes un componente con props dependientes. Por ejemplo, un componente de texto que trunca el texto con una prop truncate y proporciona una prop show expand. Para garantizar una mejor experiencia de desarrollo, queremos hacer que la prop show expand dependa de la prop truncate. Podemos lograr esto definiendo props comunes, usando una unión discriminante para la prop truncate y creando una intersección de props comunes y props truncate. Finalmente, tanto truncate como show expanded se tipan como Booleanos opcionales.
Y, ya sabes, sabemos cómo va eso. Correcto. Bueno, veamos un patrón avanzado. Correcto. A veces tienes un componente y tiene props dependientes. Digamos que tienes este componente de texto que te permite truncar el texto con una prop truncate. Correcto. Y también tiene una prop show expand para proporcionar un enlace, un pequeño enlace para hacer clic y expandir el texto truncado. Bueno, la prop show expand no tiene mucho sentido sin la prop truncate. Así que queremos que esa configuración sea un error. Correcto. Es una mejor experiencia de desarrollo para los usuarios del componente de texto. Si ese es el caso. Entonces, ¿cómo hacemos esto posible? ¿Cómo obtenemos este error en la parte inferior para esas configuraciones no válidas? Bueno, hay un par de formas en las que puedes configurarlo. Y esta es mi enfoque preferido. Primero defines tus props comunes, que son las props que siempre existirán sin importar qué. Correcto. Luego, el tipo de props truncate es lo que se llama una unión discriminante. Vale. Término elegante. Pero solo significa que varios objetos se combinan juntos uno u otro. Entonces, dentro de ese primero está la prop truncate cuando la prop truncate es false. O undefined, por lo que no se especifica. En este caso, vamos a establecer show expand como undefined. La traducción básicamente es que show expand no se puede establecer cuando truncate es false o undefined. Muy bien. Y luego, en segundo lugar, cuando la prop truncate se establece específicamente en true y solo true. Entonces, cuando está activado, en este caso, show expanded es un Booleano opcional. Ahora se nos permite hacer esta configuración adicional. Entonces, props es la intersección o la combinación de props comunes y props truncate. Básicamente, son todas las props juntas. Y finalmente, en el código, tanto truncate como show expanded se tipan como Booleanos opcionales.
7. Type Safety and Advanced Pattern
Puedes usar las props según sea necesario en el código y asegurarte de que existan. Vamos a explorar otro patrón avanzado para la seguridad de tipos. Queremos admitir todas las props del elemento de botón y garantizar la comprobación de tipos. Actualmente, confiamos en los errores en tiempo de ejecución de React para la validación. Hagamos esto seguro en cuanto a tipos definiendo nuevas props e intersectándolas con las props del elemento de botón. Si hay un conflicto, sobrescribimos la variante y el tamaño con las nuevas props.
Entonces puedes usarlas según sea necesario dentro del código y verificar que existan como sea necesario.
De acuerdo. Entonces veamos otro patrón avanzado. Digamos que tengo mi componente de botón, ¿verdad? Eso es un envoltorio sobre HTML y el botón HTML. Tiene algunas props para controlar el diseño visual en la parte superior, como la variante y el tamaño. Pero también quiero admitir todas las props de los elementos de botón, como poder pasar el tipo en el clic, deshabilitado, etc., etc., etc. Y, por supuesto, quiero que todas sean verificadas por tipos.
Todo esto se trata de la seguridad de tipos. Ya hacemos este tipo de cosas sin tipos. En TypeScript, pasamos un montón de props desconocidas a un elemento de botón subyacente. Pero no hay validación en JavaScript básico. Podría pasar cualquier prop y estamos confiando en los errores en tiempo de ejecución de React para decirnos, oh, espera, espera. No puedes pasar un atributo href a un elemento de botón. Y se quejará en la consola de errores.
Bueno, intentemos hacer esto seguro en cuanto a tipos. En cambio, esto es cómo podría verse nuestra definición de TypeScript. Nuevamente, hay varias formas diferentes de lograr esto, pero esta es la forma en que me gusta hacerlo. De acuerdo. Primero, defines las nuevas props. Y lo llamo nuevas props como la interfaz. En este caso, serán variante y tamaño. Estas son las cosas que están por encima de lo que tiene un elemento de botón. Luego queremos definir las props como la intersección de las nuevas props y todas las props del elemento de botón. Pero puede haber una posibilidad de que el elemento de botón ya tenga una prop de variante o tamaño en él. Así que aquí está el truco. En ese caso, queremos sobrescribir la variante y el tamaño con los que están en las nuevas props.
8. TypeScript y Props del Elemento de Botón
Pero cuando hay colisiones de nombres e interfaces y tipos, cosas extrañas suceden en TypeScript. Queremos todas las props del elemento de botón, excepto las nuevas que estamos definiendo. En el código del componente, podemos expandir las props del botón como siempre lo hacemos, excepto que ahora las props del botón están completamente tipadas. Por último, digamos que tienes un componente de lista que tiene una prop de renderización para cada elemento. La lista debe poder manejar diferentes tipos. Queremos poder conocer el tipo del parámetro del elemento en la prop de renderización en función del tipo de la prop del elemento. Así es como lo logramos.
Pero cuando hay colisiones de nombres e interfaces y tipos, cosas extrañas suceden en TypeScript. Aún no estoy seguro de qué son esas cosas, pero sé que suceden. Por lo tanto, queremos todas las props del elemento de botón, excepto las nuevas que estamos definiendo. Así es lo que hace esta línea. Usamos 'keyof' para obtener todos los nombres de propiedades de las nuevas props. Eso sería 'variant' y 'size'. Luego, eliminamos u omitimos esas props usando el genérico de utilidad 'omit'. Así que las eliminamos de las props del elemento de botón. Finalmente, fusionamos esas props en las nuevas props y tenemos nuestro tipo para las props del botón.
Finalmente, en el código del componente, podemos expandir las props del botón como siempre lo hacemos, excepto que ahora las props del botón están completamente tipadas. Sabe que 'type' está ahí. 'onClick' está ahí. Todos los atributos que tiene un botón. Ahora, los usuarios del botón no podrían especificar una prop 'href', por ejemplo, u otra prop que no exista porque no está en el tipo. Obtendríamos un error.
Por último, la última característica que quiero mostrarte es, digamos que tienes un componente de lista que tiene una prop de renderización para cada elemento. Pero, la lista es genérica, por lo que no sabe qué tipo de elementos está recibiendo porque no le importa realmente qué elementos está recibiendo. Solo los muestra y tal vez tiene divisores entre ellos o algo así. Es la prop de renderización la que se encarga de renderizar la interfaz de usuario real de los elementos. Mi mayor problema con las props de renderización en general es que literalmente no tengo idea de qué estoy recibiendo cuando no uso TypeScript. Así que, ahora con TypeScript, en este caso, la lista debe poder manejar diferentes tipos. A la izquierda, pasamos un array de cadenas y llamamos a '.length' en cada elemento. A la derecha, tenemos un array de números y llamamos a '.toFixed' en los datos solo para demostrar que estamos llamando a diferentes propiedades. Entonces, queremos poder conocer el tipo del parámetro del elemento en la prop de renderización en función del tipo de la prop del elemento, ¿verdad? Tenemos que tener esa relación. Y, en este caso, no estamos tipificando qué es el elemento, por lo que todo se basa en lo que hay en 'items'. Así que, puedes imaginar si 'items' fuera un array de objetos, por ejemplo, cuánto más necesaria sería este tipo de funcionalidad. Así es cómo lo logramos. Como dije, una prop de renderización es solo una función especial que devuelve React.
9. TypeScript Genéricos y Recursos de React
Pero se puede escribir con tipos al igual que cualquier otra función de prop. El componente de lista primero define un parámetro genérico T. Luego pasa T a la interfaz. La prop de renderizado recibirá elementos de tipo T. Los genéricos son críticos y útiles en el código compartido. Genéricos de TypeScript para personas que renunciaron a entender los genéricos. La hoja de trucos de TypeScript para React proporciona recetas para situaciones comunes. TypeScript funciona tanto para componentes de función como para componentes de clase. Periodicamente organizo talleres remotos de React llamados mini shops, incluyendo TypeScript para desarrolladores de React. Visita benmbp.com para obtener más información.
Pero se puede escribir con tipos al igual que cualquier otra función de prop. Y, con el poder de los genéricos, se puede escribir de forma genérica. Entonces, el componente de lista primero define un parámetro genérico T. Eso está entre los corchetes angulares allí. Luego pasa T a la interfaz. Entonces, las props de T. Y luego, dice que los elementos son una matriz de estos tipos T. No sabemos qué es T, pero es un tipo genérico. Y luego, la prop de renderizado recibirá elementos de tipo T. Entonces, T es maleable. Puede cambiar dependiendo de cómo se renderice el componente. Entonces, cuando renderizo una lista y paso cadenas, T ahora es una cadena. Pero cuando renderizo una lista y paso números, T ahora es un número. Entonces, la lista es genérica, o parametrizada como yo la llamo. Una cosa rápida que quiero mencionar es que este pequeño ángulo T coma, es un poco extraño y no es lo que normalmente harías con genéricos, pero la coma es necesaria cuando defines un componente usando funciones de flecha. De lo contrario, el analizador no puede diferenciar entre JSX o una función de flecha. Los genéricos son bastante desafiantes al principio, como podrías estar sintiendo si nunca los has visto antes, pero también son realmente críticos y útiles en el código compartido. He incluido este enlace al final como un recurso para ti. Genéricos de TypeScript para personas que renunciaron a entender los genéricos. Bastante épico.
De acuerdo, también tengo otros recursos aquí para ti. El más útil probablemente sea el que está en la parte superior, la hoja de trucos de TypeScript para React. Proporciona muchas recetas para situaciones comunes. También solo hablé sobre componentes de función, pero TypeScript también funciona para componentes de clase. Quiero decir, los hooks son el futuro, así que deberías estar usando funciones. Pero si quieres usar clases, algunos de estos recursos tienen ejemplos para ti allí.
Antes de terminar, periódicamente organizo una serie de talleres remotos de React de tres horas de duración. Los llamo mini shops y uno de ellos se llama TypeScript para desarrolladores de React. Así que si estás interesado en aprender más de forma práctica sobre TypeScript y React, haciendo ejercicios y cosas así, deberías echarle un vistazo. Solo visita mi sitio web, benmbp.com, y los verás listados allí.
10. Sorteo gratuito y conclusión
Tengo otros también que puedes ver allí, de cero a React con hooks, que es una introducción a la migración de componentes de clase a React hooks y cosas así. Estoy haciendo un sorteo gratuito para los asistentes a la conferencia para celebrar el quinto aniversario de React Summit. Así que si vas a mi sitio web de nuevo, benmbp.com, ve a la página de mini shops, encuentra uno, un mini shop que te guste y al que puedas asistir, y envía un tweet con el enlace. Etiquétame para que sepa que lo has enviado y elegiré a alguien para darle una entrada gratuita. Y puntos extra, si puedes incluir una selfie tuya viendo esta charla o durante el turno de preguntas y respuestas. Espero que lo hayas encontrado interesante y que te haya motivado a usar TypeScript en tu próximo proyecto o incluso en tu proyecto actual de React. Las diapositivas ya están disponibles en línea. Visita bennvp.com. Si tienes preguntas, no dudes en contactarme en Twitter, en bennnvp, y podemos hablar allí. Muchas gracias. Soy un gran fan de TypeScript, así que siempre aprecio una buena charla sobre TypeScript.
Tengo otros también que puedes ver allí, de cero a React con hooks, que es una introducción a la migración de componentes de clase a React hooks y cosas así.
Lo que quiero que sepas es que estoy haciendo un sorteo gratuito para los asistentes a la conferencia para celebrar el quinto aniversario de React Summit.
Así que si vas a mi sitio web de nuevo, benmbp.com, ve a la página de mini shops, encuentra uno, un mini shop que te guste y al que puedas asistir, y envía un tweet con el enlace.
Etiquétame para que sepa que lo has enviado y elegiré a alguien para darle una entrada gratuita.
De acuerdo. Y puntos extra, si puedes incluir una selfie tuya viendo esta charla o durante el turno de preguntas y respuestas. De acuerdo. Sorteo gratuito allí. De acuerdo.
Eso es todo. Lo sé. Te he inundado en 20 minutos con un montón de información. Espero que lo hayas encontrado interesante y que te haya motivado a usar TypeScript en tu próximo proyecto o incluso en tu proyecto actual de React. Eso sería genial. De nuevo, las diapositivas ya están disponibles en línea. Visita bennvp.com. Sigo enviándote allí. Las diapositivas están allí. O puedes seguir ese enlace de Bitly.
Si tienes preguntas, no dudes en contactarme en Twitter, en bennnvp, y podemos hablar allí. De acuerdo. Gracias. Y espero que disfrutes el resto de la conferencia. Muchas gracias. Soy un gran fan de TypeScript, así que siempre aprecio una buena charla sobre TypeScript. De hecho, tenemos un montón de preguntas de la audiencia. Así que voy a empezar de inmediato. En primer lugar, tus hijos son súper lindos. Bien hecho.
11. TypeScript y Rest Props
Las rest props siempre están tipadas en TypeScript, asegurando seguridad en tu código.
Gracias. Muchas gracias. Muy bien. Alguien preguntó, ¿qué hay de los puntos suspensivos que se propagan ciegamente a los subcomponentes, supongo que se refiere a una prop? Esa es la capacidad de poder tipar el resto de los parámetros que se pasan a tus props. Hablé un poco de eso al final, que hay una forma de tipar ese tipo de cosas. Así que tienes que poder comunicarle a TypeScript. Hacerle saber que es un. Esto son situaciones diferentes. Así que si defines ocho props y solo extraes tres props, las rest props tendrán las otras cinco. Así que siempre serán tipos. Así que cualquier cosa en TypeScript es tipo. Ya no hay un cajón de objetos. Hay varias formas diferentes de hacerlo más sofisticado. Pero el resultado es que las rest props siempre están tipadas.
12. Uso de Tipos e Interfaces para Props
Cuando se utiliza TypeScript para props, no hay mucha diferencia entre tipos e interfaces. Depende de la preferencia. Tiendo a usar interfaces para props base, pero los tipos son útiles para props más sofisticadas como uniones discriminadas.
Seguridad primero. Muy bien. Nuestro equipo pregunta cuándo usarías un tipo para tus props y cuándo usarías una interfaz. Así que me hacen esta pregunta todo el tiempo. Correcto. Y creo que esto es tal vez solo un problema con TypeScript. Tal vez lo llamaré ni siquiera un problema, sino simplemente una confusión con TypeScript. Incluso en su documentación donde hablan de TypeScript versus interfaces, entran en todas estas sutilezas sobre las diferencias. Y básicamente lo que es, es que el noventa y cinco, noventa y seis, noventa y ocho por ciento del tiempo no hay diferencia. Puedes hacer exactamente lo mismo con interfaces que con tipos. Así que realmente depende de la preferencia. Tiendo a usar interfaces para mis props simplemente porque así es como lo aprendí. Y tiene sentido en mi modelo mental, pero también puedes usar tipos. Y puedes extender tipos al igual que puedes extender interfaces, solo una sintaxis diferente. Pero una vez que comienzas a usar props más sofisticadas y tal vez uniones discriminadas como mostré allí, terminarás usando tipos. Pero para las props base, solo uso interfaces.
Genial. Entonces, para responder a la pregunta, no hay mucha diferencia. Pero las interfaces son las populares. Al menos para mí y la mayoría de la documentación que veo. Lo mismo. Lo decimos ambos, así que eso debe ser como es. Por supuesto, porque somos los expertos, ¿verdad? Exactamente.
13. Migración a TypeScript y Conversión de Flow
La migración a TypeScript desde no TypeScript debe hacerse de forma incremental. Comienza con archivos que no tienen dependencias y avanza desde allí. La conversión de Flow a TypeScript puede ser desafiante, pero existen bibliotecas como Flow to TypeScript y herramientas como la de Airbnb que pueden ayudar a automatizar el proceso.
Esta es... oh, me encanta esta pregunta. Estoy seguro de que la recibes todo el tiempo. ¿Tienes alguna opinión sobre la migración a TypeScript desde no TypeScript, pero también desde Flow? Sí. De acuerdo. Eso es interesante. Entonces, desde no TypeScript, mi sugerencia siempre es migrar de forma incremental. No hagas una reescritura completa en una sola PR que diga `ahora estamos en TypeScript`. Nada de eso, por favor. Si vas a hacerlo de forma incremental, el enfoque más fácil es tomar los archivos que no tienen dependencias, en los que todo lo demás depende, y comenzar con esos, y luego avanzar hasta llegar a la aplicación principal. Porque es mucho más fácil importar un archivo JavaScript, es mucho más fácil importar un archivo TypeScript desde un archivo JavaScript que al revés, porque un archivo TypeScript necesita la información de tipos, así que avanza en ese sentido, y esa es una buena estrategia. La transición desde Flow es algo interesante en lo que no había pensado en mucho tiempo. Así que escribí una de mis aplicaciones originales en Flow hace años, y recientemente intenté convertirla a TypeScript. Lo hice manualmente y no fue tan bien, pero eso se debió principalmente a que había algunas diferencias importantes entre Flow. Era un Flow muy antiguo, pero he visto algunas bibliotecas, hay una biblioteca de Khan Academy. Se llama Flow to TypeScript, básicamente, o Flow to TS, algo así que la gente puede consultar, así que tal vez haya una forma de automatizarlo también. Por último, acabo de enterarme de que hay una herramienta de Airbnb, no sé su nombre pero lo buscaré, que va desde JavaScript básico a TypeScript, así que toma tu JavaScript básico, lo convierte en un AST, un AST de Babel, más o menos, y luego lo convierte en TypeScript. Así que quién sabe qué tan legible es ese TypeScript. Tendré que echar un vistazo y ver cómo es, pero esa también es una opción para comenzar tu viaje con TypeScript.
14. Adecuación de TypeScript para Proyectos
TypeScript no es adecuado para bibliotecas que no deben ser transpiladas, pero para todo lo demás, es una buena opción. La decisión de usar TypeScript depende de la experiencia del equipo. Para proyectos pequeños, puede que no valga la pena aprender TypeScript, pero para proyectos más grandes con más personas, tiene sentido aprender TypeScript. Una vez que conoces TypeScript, no hay razón para no usarlo.
Bien, si una computadora lo hizo, ¿quién sabe? De acuerdo. Melanie pregunta, ¿para qué proyecto no es adecuado TypeScript, si es que hay alguno? Melanie, así que creo, bueno, creo que lo único para lo que TypeScript no es adecuado es para una biblioteca que no debe ser transpilada en general. No tiene nada que ver con TypeScript, pero si estás escribiendo algún script de nodo o lo que sea y necesita ser lo más pequeño posible porque se usa todo el tiempo, entonces probablemente solo quieras escribirlo en ES5 puro y no realizar ninguna transpilación. Aparte de eso, diría que TypeScript es una buena opción para cualquier cosa. Solo depende de la experiencia del equipo en cuanto a si conocen TypeScript. Entonces, si es algo realmente pequeño y las personas no conocen TypeScript, entonces no tiene mucho sentido aprender TypeScript para esa pequeña cosa. Pero si es algo pequeño y yo lo estoy escribiendo, lo escribiré en TypeScript porque ya lo conozco. La curva de aprendizaje ya la he superado. Así que cuanto más grande sea el proyecto y más personas haya en él, más sentido tiene aprender TypeScript desde el principio, diría yo. Esa podría ser la pregunta detrás de lo que ella estaba preguntando. Pero en general, una vez que conoces TypeScript, no hay razón real para no usarlo en nada. Sí, de hecho, tenemos una pregunta aquí que creo que ya respondiste un poco, pero quiero hacerla de todos modos para ver si tienes alguna otra idea, que es, en primer lugar, gran charla, Ben, con lo que estoy de acuerdo. ¿Hay alguna desventaja de usar TypeScript en comparación con no usarlo, en tu opinión? Entonces, la desventaja de usar TypeScript es si no lo conoces bien, porque habrá casos en los que escribas código que sabes que debería funcionar o incluso funciona cuando lo ejecutas, pero TypeScript no está contento. Entonces ahora te encuentras teniendo que complacer a TypeScript para poder avanzar y en lugar de construir realmente tu aplicación. En cada etapa, habrá cosas nuevas que aprender sobre TypeScript. Ahora aprendes sobre genéricos. Ahora aprendes sobre uniones discriminantes. Ahora aprendes sobre lo que sea que venga después. Y en ese momento es difícil tener esa información. Así que creo que ya olvidé un poco cuál era la pregunta, pero no hay, no hay una desventaja real en general, en términos holísticos, de usar TypeScript. Porque al final, tener esos tipos asegura que tu código siempre sea seguro en cuanto a tipos. Así que nunca estarás desreferenciando un objeto indefinido o tratando algo como un número cuando debería ser una cadena, etc., etc., etc. Muy bien. Bueno, se nos acabó el tiempo. Ben, muchas gracias por unirte a nosotros y responder nuestras preguntas. Que tengas un buen día.
Comments