TypeScript + React = ❤️

¡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.

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.

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.

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.

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.

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.

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í.

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.

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.

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.

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.