¿Qué tan tipado es tu framework?

♪ Muchas gracias por recibirme. No pueden imaginar lo emocionado que estoy de estar aquí hoy. Está bien que la diapositiva sea negra, todo está bien. Hola a todos, también a todos los que están viendo de forma remota. Espero que estén disfrutando de la conferencia.

Antes de presentarme, quiero mostrarles algunos pequeños fragmentos de código y hacerles una pregunta simple. ¿Esto les parece divertido? Cuando vemos esto, parece lo suficientemente inocente. Lo enviamos a producción, ejecutamos nuestro código y nos encontramos con este hermoso error en tiempo de ejecución. Error de referencia no capturado, la ruta no está definida. Por supuesto, estos errores en tiempo de ejecución siempre nos muestran la pequeña línea donde ocurre el error en nuestro código. Así que es bastante fácil detectar que cometimos un pequeño error tipográfico. Por supuesto, corregimos el error, terminamos el día, enviamos el código a producción, nos vamos al fin de semana y, por supuesto, el sábado por la mañana, el cliente nos llama y nos dice que aún no funciona. Nos encontramos con otro error en tiempo de ejecución.

Errores como estos son exactamente la razón por la cual TypeScript ha ganado popularidad en los últimos años. Porque, por supuesto, las principales promesas, ese tipo de problemas y errores, nunca aparecerán en tiempo de ejecución si estás trabajando con TypeScript. Así que vas a tu líder técnico y lo convences de convertir, de migrar toda tu base de código a TypeScript. Porque tal vez sea un proyecto más antiguo y aún estés trabajando con componentes de clase e incluso estás utilizando APIs heredadas, como las StringRefs heredadas. Como puedes ver, este ya es código de TypeScript, pero aún así tenemos el mismo error en tiempo de ejecución. Aquí estamos pasando un StringRef a la div para obtener una referencia al nodo HTML y en la raíz de la cadena. Y accedemos a esto en la parte superior con this.refs.root, pero nuevamente con el mismo error tipográfico. Como puedes ver, solo porque estamos usando TypeScript no garantiza que no tengamos ningún error en tiempo de ejecución. Depende del framework, depende de las APIs que estamos utilizando qué tan seguros estamos realmente. Y este es exactamente el tema de mi charla que les voy a dar ahora. ¿Qué tan tipado es realmente React y cómo se compara con otros frameworks?

Pero primero, me voy a presentar porque supongo que la mayoría de ustedes no me conocen. Mi nombre es Andreas y soy de Dresden, Alemania, y soy líder de desarrollo en una pequeña agencia. Y alrededor de 2016, comenzamos a migrar nuestro primer proyecto a TypeScript y desde entonces hemos sido grandes fanáticos. Así que cada nuevo proyecto que comenzamos, de ninguna manera comenzamos con JavaScript, tiene que ser TypeScript o no estamos dentro. Y supongo que muchos de ustedes o algunos de ustedes están compartiendo un viaje similar. Y este aumento en popularidad ha llevado a muchos de los frameworks populares a agregar una oración como esta a su documentación. Ofrecemos soporte de TypeScript de primera clase.

TypeScript funciona de manera nativa. En primer lugar, TypeScript es un ciudadano de primera clase en nuestro framework. Curiosamente, tal vez ya lo hayas visto, ayer lanzaron la versión más reciente de la documentación de React como una versión beta temprana y busqué en la documentación y hasta ahora no hay nada como eso en la documentación beta, pero veremos, tal vez se agregue más adelante. Echa un vistazo a los frameworks populares.

Mucho ha cambiado en los últimos años. En primer lugar, Vue.js cuando anunciaron la versión 3.0, anunciaron que habían reescrito completamente el framework basado en TypeScript y ahora pueden ofrecer una experiencia mucho mejor que en las versiones anteriores de Vue. Angular también, aunque comenzaron con TypeScript hace muchos años, comenzaron tan temprano con TypeScript que TypeScript aún no era lo suficientemente poderoso para modelar todas las características dinámicas que el framework necesita ofrecer a sus usuarios. Lamentablemente, en el frente de React, las cosas han estado un poco estancadas. Pero esto no es un problema en absoluto porque desde el principio, cuando TypeScript tomó la decisión de admitir directamente JSX o TSX, nunca hemos tenido problemas con el soporte de TypeScript, por lo que en ese aspecto, aunque no haya cambiado mucho, aún podemos obtener los beneficios de TypeScript en nuestro código.

A continuación, quiero analizar diferentes áreas del framework que pueden ser compatibles con TypeScript. Primero, vamos a echar un vistazo a lo básico. Dentro de un componente, tienes esta parte lógica donde llamas a funciones, defines variables y pasas estas partes lógicas a la plantilla, y esta plantilla luego accede a esas variables. Pero esto es solo lo básico, es el nivel más bajo de soporte de tipos que un framework puede ofrecer. El requisito mínimo para poder ayudarnos como desarrolladores es cuando los límites entre componentes también están tipados. Las entradas, los datos que fluyen hacia nuestros componentes y las salidas, los eventos que salen de él, también deben ser seguros en cuanto a tipos para brindarnos beneficios. Pero comencemos con lo básico. Tal vez ni siquiera estemos trabajando con TypeScript, tal vez todavía estemos trabajando con JavaScript. TypeScript ya puede ayudarnos en nuestro framework elegido. Aquí, tal vez reinstalamos las definiciones de tipos de React en nuestro proyecto. Entonces, cuando escribimos react.use, obtenemos autocompletado, obtenemos una sugerencia de qué funciones queremos usar allí mismo. Más tarde, migramos nuestro proyecto y luego, todavía estamos en la parte lógica de nuestro componente, pero aquí, TypeScript puede ayudarnos y mostrarnos errores cuando cometemos un pequeño error tipográfico o usamos una función que no existe. Cuando queremos usar estos datos, esta lógica en nuestras plantillas, TypeScript nuevamente quiere ayudarnos. Aquí, definimos un número y queremos usarlo en la interfaz de usuario, en la parte de la plantilla, y aquí también, TypeScript puede ayudarnos y brindarnos las sugerencias correctas. Y como puedes ver a la derecha, cuando accedemos a una función que no existe, nuevamente vemos el error en el editor. Una parte muy importante es que no solo queremos ver el error en nuestro editor porque cuando escribimos código, tal vez vamos demasiado rápido para TypeScript en segundo plano cuando está compilando, a veces lleva un poco de tiempo, tal vez ya cerraste tu archivo, lo enviaste a producción o lo enviaste a tu canalización y luego queremos poder interrumpir la canalización de compilación si todavía tenemos errores tipográficos en nuestro proyecto. Por lo tanto, el framework debe ofrecer una posibilidad para que podamos ejecutar las verificaciones de tipos con la herramienta de línea de comandos. Afortunadamente, porque TypeScript admite directamente JSX, podemos simplemente ejecutar TSC, el compilador de TypeScript y hacer que los errores interrumpan la canalización de compilación. En el siguiente paso, puede volverse un poco más complejo cuando queremos usar más características que TypeScript nos ofrece. Como aquí, tenemos nuestro componente que recibe como prop y un valor x, que puede ser un número o una cadena. Por supuesto, no podemos estar seguros de qué recibimos en nuestro caso de uso.

Entonces, cuando llamamos directamente a la función toFixed en x, TypeScript puede ofrecernos esta ayuda para errores y decirnos que está bien que toFixed exista en un número, pero en el tipo string, la función toFixed no existe. Por lo tanto, TypeScript nos obliga a verificar primero si la variable x realmente es un número. Y solo entonces podemos acceder a las funciones que existen en los números.

Esta es una característica que se ha agregado a los otros frameworks bastante tarde en realidad. Por ejemplo, aquí estamos viendo el código equivalente en Vue.js. Básicamente tenemos lo mismo si definimos una propiedad que es un número o una cadena y la usamos en la plantilla. Y obtenemos exactamente el mismo error que antes porque en Vue.js encontraron una forma de compilar las plantillas en código TypeScript real y tener los mismos tipos de errores que obtenemos nativamente con el compilador de TypeScript en React.

Ahora que tenemos los conceptos básicos, podemos definir la lógica de nuestros componentes de manera segura en cuanto a tipos. Podemos acceder a esta lógica en nuestras plantillas y tener la ayuda de TypeScript en todo momento. Ahora pasemos a los límites entre componentes. Aquí, tenemos nuestro componente B que recibe como entrada un valor x como número y proporciona una salida que también es un número. Cuando estamos usando ese componente a la derecha, por supuesto, queremos asegurarnos de que lo estamos utilizando correctamente. Entonces, aquí estamos pasando una cadena en lugar de un número, TypeScript puede ayudarnos allí. Lo mismo ocurre con las salidas, hemos definido que set x siempre se llama con un número, por lo que también obtenemos ayuda de TypeScript allí.

Una cosa muy interesante es que este tipo de errores no son compatibles con todos los principales frameworks. Para nosotros, los desarrolladores de React, es bastante natural que si definimos dos propiedades, x y set x, entonces debemos proporcionarlas al usar el componente, pero esto no es algo que se dé por sentado en todos los demás frameworks. Ahora que tenemos los conceptos básicos y como dije antes, especialmente desde los últimos cambios en los otros frameworks, realmente han alcanzado a React en ese sentido, pero aún hay algunas ventajas adicionales que React nos ofrece y que los demás no pueden o no pueden brindarnos fácilmente como desarrolladores.

En primer lugar, lo genial de React es que los componentes son solo funciones. Es como dice la documentación, es solo JavaScript. Es un hermoso ensamblaje. Como aquí mismo, tenemos nuestro componente de botón. Tal vez incluso sea de una biblioteca donde tenemos props tipados. El problema es que tal vez esta biblioteca no exporta esta interfaz como un tipo explícito, sino que solo exporta el componente. Pero debido a que en React los componentes son funciones simples, podemos usar los ayudantes de TypeScript para acceder a la forma de este argumento. Podemos usar el tipo de parámetros, extraer la interfaz y extraer el tipo de la función de botón, y el tipo de parámetros nos devolverá una lista de los parámetros que nuestra función espera. Entonces, aquí mismo en nuestro ejemplo, un componente de React siempre recibe un argumento, el objeto de props, por lo que usamos el índice cero para extraer las props de nuestro componente de botón. Así que solo porque el autor de la biblioteca decidió no exportar directamente el tipo del componente de botón, aún podemos acceder a él con los parámetros. Sin embargo, en este momento esto solo funciona con componentes de función, pero afortunadamente las definiciones de tipos de React exportan un tipo de ayuda llamado component props que podemos usar para acceder a las props de componentes de función, de componentes de clase y de los elementos HTML incorporados.

Entonces, por ejemplo, aquí estamos extrayendo todas las propiedades que se permiten en el elemento HTML nativo. Esto es muy útil para definir envoltorios muy delgados alrededor de otros componentes. Por ejemplo, aquí queremos un pequeño envoltorio alrededor del componente de botón HTML donde podemos pasar otra propiedad, un icono. Así que simplemente estamos extrayendo todas las propiedades del elemento de botón HTML y uniéndolas con el operador de intersección, uniendo algunas nuevas propiedades como aquí, la prop opcional de icono. En nuestro componente, luego podemos desestructurar nuestras props, pasar el icono y usarlo de alguna manera en nuestro componente, y pasar las props restantes al botón. Y lo bueno es que si por alguna razón HTML agrega otra propiedad al botón HTML, esto seguirá funcionando y seguirá siendo completamente seguro en cuanto a tipos. Por lo tanto, no tenemos que repetir todas las props que están presentes en el botón HTML, sino que podemos tomar las props del botón HTML y unirlas en nuestros tipos de props. También podemos aprovechar este patrón para intercambiar componentes en nuestras aplicaciones de manera segura en cuanto a tipos. Entonces, aquí, por ejemplo, tenemos esta aplicación personalizable. Allí estamos definiendo como argumento que queremos recibir cualquier componente que cumpla con la interfaz de nuestro componente de botón. De esta manera, podríamos construir un marco donde los botones sean personalizables, intercambiables, tengan un comportamiento diferente y los usuarios de nuestro marco solo puedan aplicar su propio componente de botón, que se usará en todas partes de la aplicación. Y aún así tenemos esto de manera segura en cuanto a tipos. Por lo tanto, deben asegurarse de que su componente de botón cumpla con la interfaz de este elemento de props de botón. A continuación, queremos echar un vistazo a otra gran característica que recibimos al tener los componentes como funciones. Tal vez hayas escuchado la charla anterior sobre la virtualización. La virtualización es una técnica donde no deseas renderizar todos los elementos de una lista, sino solo los elementos que están actualmente visibles en la pantalla.

Y aquí, estamos construyendo un pequeño componente ficticio que hace exactamente eso. Definimos la interfaz aquí para recibir un recuento de elementos y una altura de elemento. Esto facilita el cálculo de qué elementos están actualmente visibles en la ventana gráfica, y pasamos una función de representación, una propiedad de representación, que podemos usar para definir cómo se representa cada elemento en la interfaz de usuario.

Por supuesto, luego tenemos que hacer algunos cálculos para determinar qué elementos están actualmente visibles, pero vamos a omitir eso por ahora, y luego simplemente iteramos sobre los índices visibles y llamamos a la función de representación. Al usar este componente, se ve actualmente algo así. Obtenemos los datos, que es una matriz de personas en nuestro caso de uso, y queremos usar nuestra lista virtualizada para representar esas personas en la interfaz de usuario. Aquí, debido a que hemos definido que el índice de representación siempre pasará un número, estamos trabajando de manera segura en cuanto a tipos. Así que accedemos a un índice en la lista de personas y accedemos al campo nombre o edad.

El problema es que tal vez no siempre tenemos una lista disponible. Tal vez sea una lista de carga lenta donde solo obtenemos los datos al desplazarnos, o es una lista de carga infinita, por ejemplo, por lo que tal vez no tengamos una matriz donde tengamos todas las personas disponibles. Idealmente, queremos que la API se vea así. Ahora, la función de representación nos da un objeto de persona y en la persona podemos acceder al nombre y la edad y no a otros campos, porque solo existen estos dos.

El problema es que, si pensamos en esto de manera ingenua, podríamos pensar que ahora tenemos que desarrollar una lista virtualizada para personas, un componente de lista virtualizada para automóviles, un componente de lista para mascotas, etc. Y, por supuesto, esta no puede ser la solución correcta. Entonces, tal vez al principio estamos cambiando la interfaz de nuestro componente de lista virtualizada para recibir propiedades desconocidas o cualquier propiedad. De esta manera, al usar este componente, puedes pasar una lista de personas, una lista de gatos, una lista de animales y funcionará. El problema está en el lado de salida, la función de representación nos pasará un elemento de tipo desconocido.

Entonces no podemos usarlo para acceder a los campos edad y nombre porque desconocido no tiene ningún campo. Ahora necesitaríamos algún tipo de contrato que podamos usar para conectar estas dos propiedades desconocidas. Y para esto, podemos usar los genéricos de TypeScript. Así que definimos esta variable TitleGenericType que luego podemos usar para definir que los elementos son de cualquier tipo con TItemArray. Y cuando se usa con el tipo persona, por ejemplo, queremos que la función de representación nos devuelva nuevamente una persona. Entonces, al usar este componente, podemos pasar una lista de personas y TypeScript sabrá que hemos instanciado el componente con el tipo persona y recibiremos el objeto de persona en la función RenderItem. Cuando pasamos el cursor sobre este elemento JSX, obtenemos esta información donde podemos ver que TypeScript ha inferido correctamente el tipo de nuestro componente. De esta manera, podemos construir un componente que se puede utilizar con diferentes tipos. Así que con personas, gatos, automóviles, lo que sea. Y seguimos siendo completamente seguros en cuanto a tipos al usar este componente.

Otro patrón bastante popular que utiliza esta característica es el ASPROP. Tal vez lo hayas usado en styled components o en motion, donde puedes pasar otro componente en el ASPROP y quieres pasar nuevas propiedades a este nuevo componente genérico. Entonces, como aquí mismo, tenemos este componente de enlace que normalmente se representa solo en una etiqueta A en la interfaz de usuario.

Pero ahora queremos representarlo como un elemento de botón y queremos poder pasar un icono adicional. Y aquí nuevamente podemos hacer uso de los genéricos de TypeScript y definir nuestro componente de esta manera. Puedes ver uno de los problemas al trabajar mucho con TypeScript. El código del componente, el código de la biblioteca, comienza a verse bastante complejo, pero estamos logrando una usabilidad muy buena para los usuarios de nuestro componente.

Aquí, por ejemplo, definimos la variable de tipo T-Component. Agregamos esta restricción de que debe ser un tipo de componente. Y luego podemos decir que nuestro componente de enlace recibirá el S-Prop donde podemos pasar cualquier componente y puede recibir todas las props que este componente pasado desea recibir en la interfaz de usuario. Ahora espero que hayas podido ver que sí, el soporte de TypeScript es bueno y todos los frameworks tienen los conceptos básicos del soporte de TypeScript, pero el soporte de TypeScript es más que solo definir los tipos dentro de la lógica de nuestro componente, dentro de nuestras plantillas, también entre los límites entre componentes, pero también hay muchos casos de uso adicionales donde podemos aprovechar TypeScript en nuestros proyectos de React.

Quiero agradecerles por escuchar mi charla, espero que tengan algunas preguntas emocionantes para mí en este momento. Les deseo mucha diversión en la conferencia restante y quiero agradecerles. Muchas gracias.

¿Les gustaría tomar asiento? Tenemos algunas preguntas y estoy bastante seguro de que habrá más preguntas a medida que avancemos. Entonces, una de las primeras, y me gusta esta porque creo que va en contra de todo lo que se supone que TypeScript ofrece. ¿Hay alguna buena excusa para usar el tipo 'any' en tu proyecto? Sí, absolutamente. Lo único que realmente nunca, nunca, nunca debes hacer en tus proyectos es dejar que un 'any' salga de un componente. Es absolutamente aceptable usar 'any' dentro de una función, dentro de un módulo, porque tal vez los tipos, estás construyendo un objeto de búsqueda, por ejemplo, donde aún no conoces todos los campos que estarán presentes en este objeto de búsqueda, entonces, simplemente agrega un 'any' en eso, agrega los campos más tarde, pero asegúrate de que el tipo de retorno de tu función esté correctamente tipado. Pero dentro de un módulo pequeño, simplemente puedes agregar un 'any', tal vez escribir una prueba unitaria para estar absolutamente seguro, pero no hay ningún problema en usarlo dentro de un módulo, pero nunca lo dejes salir del módulo, porque entonces se propagará como un incendio forestal. Nunca dejes que 'any' salga, definitivamente.

Siguiente pregunta, ¿cuándo usarías React Node en lugar de elementos JSX como tipo de retorno? Personalmente, casi siempre usamos React Node porque es un poco más flexible. React Node es básicamente todo lo que se puede renderizar por React, no solo un elemento JSX, sino también null, undefined, true, false, cadenas, números y lo que sea, un poco más flexible. Bien. Y otra pregunta, ¿qué crees que es la parte más débil o más difícil de trabajar con React y TypeScript? Creo que la parte más difícil son los mensajes de error que los tipos te darán. Especialmente tal vez alguno de ustedes, tienen experiencia allí, cuando están trabajando con GraphQL y escriben un generador de código para sus tipos de GraphQL, reciben este objeto tipado masivo que, sí, muestran exactamente qué tipo de campo reciben del backend, pero cuando falta un campo allí, tal vez lo pasas a un componente, falta un campo, el mensaje de error es simplemente, es tan grande y los nuevos desarrolladores tienen, o incluso los desarrolladores intermedios, realmente tienen dificultades para identificar dónde está realmente el error en este mensaje tipado, y esto puede ser realmente confuso, y esto es algo que aún necesita mejorar, como digo. Siempre hay margen de mejora. Y volviendo a la pregunta anterior sobre 'any', ¿cuál prefieres usar, 'any' o 'unknown'? Si absolutamente tienes que hacerlo, obviamente nunca lo dejarás salir del componente. Entonces, diría que dentro de un módulo, elemento, función, lo que sea, diría que está bien usar 'any' porque entonces eres libre de hacer lo que quieras con esa variable. Si tienes un caso en el que esperas algún tipo de variable desde afuera, por lo que estás escribiendo tu propia función de registro, tal vez, y los usuarios pueden suministrar cualquier valor que deseen, usaría 'unknown', porque entonces no puedo usar accidentalmente ningún campo en estos datos, porque no sabré qué datos se están pasando. Por ejemplo, si escribo una función de registro que simplemente dice JSON.stringify, entonces realmente no importa.

Entonces, simplemente escribo 'unknown' allí y puedo estar seguro de que no accederé a ningún campo que no exista. Creo que también es bueno porque realmente se está pensando en todas estas cosas desde la fase de diseño y no se está haciendo ninguna suposición. Absolutamente. Ahora, mencionaste al principio que muchas veces hay muchas personas que pasan de JavaScript a TypeScript, ¿cómo recomendarías acercarse a TypeScript a un equipo que es nuevo en su uso o que nunca lo ha utilizado antes? Entonces, diría que, creo que Mark Erickson de React, del equipo de Redux, siempre hace esta distinción entre ser un desarrollador a nivel de aplicación y un desarrollador de bibliotecas. Y usar TypeScript a nivel de aplicación es realmente bastante cómodo porque obtienes el autocompletado, casi nunca tienes que especificar los tipos tú mismo, los tipos pueden inferir muchos tipos. Solo se vuelve realmente complejo cuando escribes tus propias bibliotecas. Entonces, tal vez diría que para un equipo que está compuesto principalmente por nuevos desarrolladores de TypeScript, diría que utilicen bibliotecas existentes, como React Query, como una biblioteca de formularios que ya tiene un sólido soporte de TypeScript para que no tengan que escribir esos tipos de biblioteca por sí mismos al principio. Pero siempre pueden hacerlo más tarde, por supuesto.

Y TypeScript se está volviendo mucho más extendido, ¿verdad? Pero obviamente, siempre hay personas nuevas que están comenzando. ¿Cuáles son los mejores recursos a los que pueden acudir las personas que vienen de, cuáles son los mejores recursos para que las personas pasen de habilidades básicas de TypeScript a comenzar a usar algunos de esos patrones avanzados de los que hablaste? Entonces, diría que un lugar realmente bueno son las hojas de trucos de TypeScript y React que Shawn Wang ha publicado en GitHub. Y además de eso, siempre recomiendo que Kenzie Dots ha escrito una publicación en el blog, sincronizar estado, derivar estado y no sincronizarlo, algo así. Y creo que esto es algo que realmente puedes aplicar a tu pensamiento sobre los tipos también. Porque cuando tienes un tipo para el tipo de datos que devuelve tu API, por ejemplo, y quieres mapear este tipo a campos de formulario que tienen un campo cambiado, un campo tocado, un campo sucio, lo que sea, entonces tienes que reconocer que esta nueva forma depende completamente de esta forma de entrada, y que de alguna manera probablemente puedas mapear este tipo de entrada a este tipo de salida esperado. Y una vez que reconoces eso, entonces puedes comenzar a buscar soluciones de cómo puedes lograr este mapeo y aprender estos patrones más complejos en el camino. Porque así es como se aprenden cosas nuevas al resolver problemas.

Muchas gracias. Eso es todo el tiempo que tenemos para preguntas hoy, pero veo que hay muchas más preguntas. Acércate y hazle algunas preguntas durante el descanso que tendremos después. Y también recuerda que habrá una Sala Espacial a la que también puedes unirte virtualmente y tener una charla. ¿Podemos todos dar un gran aplauso a Andrés? Muchas gracias por tenerme aquí.