¿Qué tan tipado es tu framework?

Rate this content
Bookmark

Estamos llegando poco a poco a un punto en el que el soporte de TypeScript es una característica imprescindible de un framework y no algo agradable de tener. Pero esta no es una pregunta simple de sí o no. Veamos las diferentes áreas del framework donde TypeScript puede ayudarte a desarrollar aplicaciones de calidad.

25 min
22 Oct, 2021

Video Summary and Transcription

La charla de hoy se centró en la importancia de TypeScript para prevenir errores en tiempo de ejecución y su integración con frameworks populares como Vue.js, Angular y React. TypeScript proporciona asistencia de errores y límites de tipado entre componentes, asegurando un uso correcto. También permite la creación de componentes genéricos, aprovechando los genéricos de TypeScript para definir contratos entre propiedades desconocidas. La charla destacó el uso de TypeScript en diversos escenarios, como trabajar con React Node, y proporcionó recursos para seguir aprendiendo y explorando.

Available in English

1. Introducción a TypeScript y React

Short description:

Gracias por recibirme. Hoy quiero mostrarles algunos fragmentos de código y discutir la importancia de TypeScript en la prevención de errores en tiempo de ejecución. También hablaré sobre cómo React con tipos se compara con otros frameworks. Mi nombre es Andreas y soy líder de desarrollo de Dresden, Alemania. Desde 2016, hemos migrado todos nuestros proyectos a TypeScript y nos hemos convertido en grandes fanáticos. Muchos frameworks populares ahora ofrecen soporte de TypeScript de primera clase.

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

2. TypeScript en los Frameworks

Short description:

TypeScript es un ciudadano de primera clase en nuestro framework. Vue.js y Angular han adoptado TypeScript, ofreciendo mejores experiencias. React, aunque estancado, aún se beneficia de TypeScript. TypeScript nos brinda soporte en lo básico y ayuda con errores y sugerencias. También puede interrumpir el proceso de compilación por errores tipográficos. Al utilizar más características, TypeScript permite establecer límites de tipos entre componentes.

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.

3. TypeScript y Límites de Componentes

Short description:

TypeScript nos obliga a verificar si la variable x es un número antes de acceder a las funciones numéricas. Vue.js tiene una característica similar para detectar errores en las plantillas. Ahora podemos definir lógica segura en cuanto a tipos y acceder a ella en nuestras plantillas. TypeScript nos ayuda a garantizar el uso correcto de los componentes y proporciona asistencia de errores para las entradas y salidas.

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

4. Componentes de React y Virtualización

Short description:

Los componentes de React son solo funciones, lo que nos permite acceder a la forma de los argumentos del componente. Podemos extraer props utilizando los ayudantes de TypeScript y las props del componente. Esto es útil para definir envoltorios delgados alrededor de componentes e intercambiar componentes de manera segura en cuanto a tipos. La virtualización es una técnica para renderizar solo los elementos visibles en una lista.

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.

5. Building a Generic Component with TypeScript

Short description:

Construimos un componente que puede ser utilizado con diferentes tipos, asegurando la seguridad de tipos. Los genéricos de TypeScript nos permiten definir un contrato entre propiedades desconocidas. De esta manera, podemos pasar listas de diferentes tipos y aún así recibir el objeto correcto en la función RenderItem. TypeScript infiere correctamente el tipo de nuestro componente. El patrón ASPROP es otro uso popular de esta característica.

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.

QnA

Using TypeScript Generics and React Node

Short description:

Podemos utilizar los genéricos de TypeScript para definir nuestro componente y lograr una buena usabilidad. El soporte de TypeScript va más allá de definir tipos en la lógica y las plantillas. Hay muchos casos de uso adicionales donde se puede aprovechar TypeScript en proyectos de React. Está bien usar 'any' dentro de un módulo, pero nunca dejarlo salir. React Node es más flexible que los elementos JSX como tipo de retorno. Los mensajes de error de los tipos de TypeScript pueden ser desafiantes, especialmente con GraphQL y la generación de código. Siempre hay margen de mejora. Si tienes que elegir entre 'any' y 'unknown', usa 'any' dentro de un módulo y 'unknown' cuando esperes variables externas.

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.

Approaching TypeScript and Resources

Short description:

Al utilizar TypeScript, es importante pensar en todos los aspectos desde la fase de diseño y evitar hacer suposiciones. Para los equipos nuevos en TypeScript, se recomienda utilizar bibliotecas existentes con un sólido soporte de TypeScript. Las hojas de trucos de TypeScript y React de Shawn Wang son excelentes recursos para aprender patrones avanzados. Comprender la relación entre los tipos de entrada y salida puede ayudar a resolver problemas complejos. Lamentablemente, se nos ha acabado el tiempo para preguntas, pero hay otras oportunidades para preguntar durante el descanso y unirse a la Sala Espacial para más discusiones.

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

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

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.