Entendiendo la Arquitectura Fiber de React

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

Hemos escuchado mucho sobre la Arquitectura Fiber de React, pero parece que pocos de nosotros la entendemos en profundidad (o tenemos el tiempo para hacerlo). En esta charla, Tejas repasará su mejor intento de entender Fiber (revisado por otros expertos), y lo presentará de una manera 'explicar-como-si-tuviera-cinco años'.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

No, no es necesario conocer los detalles internos de Fiber para desarrollar aplicaciones con React. React está diseñado para ser utilizado de manera efectiva sin necesidad de entender sus componentes internos como Fiber.

Los elementos en React son descripciones declarativas del estado deseado de la UI y son efímeros, mientras que los Fibers son estructuras de datos duraderas y con estado que React usa internamente para rastrear y manejar el trabajo de reconciliación de la UI.

La reconciliación en React es el proceso de comparar y actualizar el árbol de elementos con su estado en el entorno anfitrión (como un navegador) para hacer efectivos los cambios. Los Fibers son fundamentales en este proceso, facilitando el manejo eficiente de las actualizaciones y la priorización de tareas.

Fiber mejora el rendimiento de las aplicaciones en React al permitir interrumpir y priorizar actualizaciones de componentes, lo que asegura que las tareas críticas se manejen de manera eficiente y que la interfaz permanezca fluida y responsiva.

La función 'create fiber from types and props' en React es responsable de crear un Fiber a partir de elementos, lo cual es esencial para el proceso de reconciliación donde React prepara y gestiona los cambios en la UI.

Fiber en React es una unidad de trabajo interna que utiliza React para rastrear y manejar los estados y actualizaciones de la UI. No está expuesto directamente al usuario, facilitando la gestión de los procesos de actualización y renderizado de manera eficiente y optimizada.

Tejas Kumar
Tejas Kumar
29 min
21 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla explora la jerga interna de React, específicamente fiber, que es una unidad interna de trabajo para renderizar y comprometer. Las fibras facilitan actualizaciones eficientes a los elementos y juegan un papel crucial en el proceso de reconciliación. El bucle de trabajo, el trabajo completo y la fase de compromiso son pasos esenciales en el proceso de renderizado. Entender los internos de React puede ayudar a optimizar el código y las revisiones de las solicitudes de extracción. React 18 introduce las funciones de sincronización y asincronización del bucle de trabajo para características concurrentes y priorización. Fiber aporta beneficios como el renderizado asincrónico y la capacidad de descartar árboles de trabajo en progreso, mejorando la experiencia del usuario.

1. Entendiendo el argot interno de React

Short description:

Bienvenidos de vuelta después del almuerzo. Esta charla es sobre el argot interno de React, específicamente fiber. Fiber es algo interno que React utiliza como una sola unidad de trabajo para renderizar y comprometer. No está expuesto a los usuarios, a diferencia de los elementos de React. Los elementos describen el estado deseado de la interfaz de usuario, mientras que los fibers son internos y efímeros. Trabajan juntos para construir grandes aplicaciones.

Bienvenidos de vuelta después del almuerzo. Espero que estén listos para algo profundo en esta conferencia tan avanzada. Permítanme comenzar diciendo que esta es una charla que nadie necesita escuchar. En serio, nadie necesita escuchar esto. Espero que algunos de ustedes quieran escuchar esto. ¿Quieren? Vale. Pero nadie, porque aquí está la cosa, esto es sobre el argot interno de React. Son cosas que podrían interesarte, como a mí, si eres curioso. No necesitas saber estas cosas para construir grandes aplicaciones con React.

React es la mejor manera de construir interfaces de usuario en la Web. Y no necesitas conocer los detalles internos para eso. ¿Quién quiere sumergirse en los detalles internos hoy solo por diversión? Sí, eso es. Vamos a hacer esto. Vamos a poner en marcha este espectáculo. Vamos a hablar de algo llamado fiber. Fiber es algo que no tengo mucho en mi... Pero, ¿qué es en el contexto de React? En pocas palabras, fiber... Y por cierto, vamos a sumergirnos en la arquitectura de fiber en 20 minutos. ¡Imagínate eso! Fiber en React es una sola unidad de trabajo. Hay una sola unidad de trabajo que React hace. Y podrías estar pensando, OK, ¿qué es el trabajo? El trabajo es esencialmente renderizar tus cosas y ponerlas en la pantalla. Renderizar y comprometer. Fiber es algo interno. De nuevo, así que no necesitas saber nada sobre ello para construir grandes aplicaciones con React. Y como tal no está expuesto a los usuarios. Así que quizás una forma más fácil de razonar sobre ello es pensar en algo que está expuesto y partir de ahí. ¿OK? ¿Qué está expuesto en React? El humilde elemento. Todos escribimos elementos de React. Escribimos un corchete angular con un nombre y eso llama a react.create element. Y tenemos elementos. Los elementos son con los que trabajamos diariamente. Y no voy a profundizar en los elementos porque ya lo hice una vez. Fue una charla relativamente popular sobre los elementos de React y cómo existen y cómo se crean y todo eso. Siéntete libre de ver eso en tu tiempo libre. Pero lo que quiero hacer es comparar y contrastar elementos y fibers para que tengamos, ya sabes, una idea de cómo trabajan juntos. Esencialmente lo que quiero resumir de esa charla para esta es que un elemento de React describe el estado deseado de la UI. Un elemento de React te permite describir, de manera declarativa, aquí está mi árbol de elementos de React. Esta es mi aplicación. Y luego React hace el trabajo de hacer eso la verdad en un entorno anfitrión. Así que en un navegador, en un dispositivo móvil con React Native, en una interfaz de línea de comandos con React, tus elementos describen lo que quieres. React hace que eso suceda. ¿Está claro? Genial. Entonces, ¿cómo entran los fibers en esta imagen? Para empezar, los elementos son públicos, es decir, son externos. Los escribimos. Pero los fibers son internos. No hablamos de ellos porque no necesitamos. Hay todo un equipo que trabaja con estos diariamente por nuestro bien, en nuestro nombre, para que podamos construir grandes aplicaciones. Los elementos son efímeros, así que no viven mucho tiempo. Puedes desechar los elementos. Puedes crear nuevos.

2. Entendiendo Elementos y Fibers

Short description:

Los elementos son efímeros, mientras que los fibers son estructuras de datos duraderas y con estado que React utiliza para rastrear el comportamiento y la apariencia de la aplicación. Los fibers facilitan actualizaciones eficientes a los elementos, evitando el re-renderizado innecesario. La reconciliación es el proceso de alinear la descripción de la interfaz de usuario con el entorno anfitrión, y los fibers juegan un papel crucial en esto.

Son solo una representación. Si hablas DevOps, son como un manifiesto de Kubernetes. Simplemente describes el estado que deseas, y luego un sistema lo lleva a cabo. O como un archivo de Terraform. ¿Algún DevOps en la sala? Oh, genial. Hola. Una persona.

Los elementos son efímeros. Los fibers son estructuras de data duraderas y con estado que React utiliza para seguir el rastro de lo que se supone que debe hacer tu aplicación. Lo que quieres que haga y cómo quieres que se vea. Y esa es la propuesta de valor de React en su totalidad.

Entonces, la forma de construir user interfaces que realiza actualizaciones eficientes y correctas a tus elementos de tal manera que no los descarte y te dé uno nuevo cada vez. ¿Puedes imaginar perder el estado de enfoque de tu entrada en cada pulsación de tecla? Desagradable. Entonces, los fibers facilitan eso. Y tercero, los elementos son inmutables. Es decir, no los cambias. Los desechas. Creas unos nuevos. Pero los fibers son estructuras de data duraderas, mutables y con estado utilizadas en el proceso de reconciliación. ¿Qué es la reconciliación? La reconciliación es cuando tomas un árbol de elementos, una descripción, un mapa de ruta de cómo quieres que se vea tu UI y cómo quieres que responda a los eventos y qué efectos quieres que tenga. Tomas esta lista de elementos y los reconcilias con un entorno anfitrión. El navegador o un dispositivo móvil o CLI. Eso es la reconciliación. Es esencialmente tomar tu descripción y hacerla la verdad. Los fibers son fundamentales en esto.

3. Entendiendo el Bucle de Fiber y el Proceso de Renderizado

Short description:

Ahora, entendemos cómo los elementos se convierten en fibers y la interacción entre ellos. El trabajo se realiza en el bucle de fiber, que establece flags y completa el trabajo en el árbol de fibers. El trabajo completo construye nodos DOM en un estado desconectado, y la fase de commit pone todo en la pantalla. La capacidad de pausar e interrumpir el renderizado es el punto principal de Fiber.

Ahora, entendemos los elementos, entendemos los fibers, entendemos la reconciliación. ¿Cómo se convierten los elementos en fibers? ¿Se convierten en fibers? ¿Cuál es la interacción? Hay una función en el código fuente code. Gracias a Dios que React es de código abierto y tiene licencia MIT. Puedo simplemente leer. Hay una función llamada create fiber from types and props. Podrías decir que esta función se llama create fiber from elements. Si has mirado un elemento de React, es un objeto JavaScript con propiedades de tipo, a veces propiedades de los hijos. Puedes decir que un fiber se deriva casi de los elementos y luego es utilizado por el reconciliador de fiber. Entendemos la reconciliación, entendemos los fibers. Todo se une en el reconciliador de fiber para hacer el trabajo de construir tus interfaces de usuario.

El trabajo se realiza en lo que se llama el bucle de fiber. Piénsalo como un bucle de juego. Cuando hay trabajo por hacer, inicias un bucle en la parte superior de tu árbol de fibers. Comienzas el trabajo. Estos son nombres de funciones en el código fuente code. Comienzas el trabajo en el nodo más alto. Y lo que hace begin work es esencialmente establecer flags. ¿Debería actualizarse esto? ¿Qué cambió? Establece un montón de flags. Y cuando termina, pasa al siguiente nodo en tu árbol. Y el trabajo comienza en eso. El siguiente siendo el hijo. Begin work establece algunas flags en eso. Si hay un hijo, simplemente sigue bajando, estableciendo flags hasta que no hay más hijos y entonces ¿qué sucede? Complete work. Ahora complete work hace algo más. También pasará al hermano como el siguiente. No el hijo. Si hay un hermano. Y luego vuelve a subir el árbol, completando el trabajo. Complete work construye nodos DOM, pero no en el DOM, en un estado desconectado. Así que no ves nada de esto en tu pantalla. Simplemente conecta nodos entre sí. Y finalmente tienes la fase de commit. Que es poner todo en la pantalla. Así que todo, hasta commit root, nada sucede en la pantalla. Y la razón de esto es, si el trabajo de renderizado necesita ser interrumpido o pausado, no es mientras el usuario está viendo que suceden cosas. Puedes desechar un árbol y recrearlo fuera de la pantalla y luego hacer el commit finalmente. Ese es el punto principal de Fiber, es la capacidad de pausar e interrumpir el renderizado y priorizar las actualizaciones. Algunas tienen alta prioridad, algunas tienen baja prioridad. Pero he estado hablando demasiado y honestamente no me gusta diseñar diapositivas. Así que simplemente dibujemos un diagrama y miremos algo de code. ¿Está bien? ¿Tengo permiso? Vale. Eso es agradable. Un woo. Vamos a conseguir esto. Así que tengo Excalidraw. Un aplauso. ¿A quién le gusta Excalidraw? Sí. Genial. Vizhou, gracias por esta herramienta. Así que vamos aquí.

4. Dibujando el Árbol de Elementos y la Reconciliación de Fiber

Short description:

Dibujamos un árbol de elementos, incluyendo un main, H1, div, span y botón. El reconciliador de fiber mantiene dos árboles: el árbol actual y el árbol de trabajo en progreso. Cuando se hace clic en el botón de más, el reconciliador de fiber actualiza el árbol de trabajo en progreso de forma desconectada y luego confirma los cambios. Comienza con el nodo principal, establece flags y se mueve a través del árbol, marcando actualizaciones y completando el trabajo.

Y lo que vamos a hacer es dibujar un árbol de elementos. Así que tenemos un main. Como hijo de main, digamos que tenemos un H1. En realidad, pongamos un div. Sopa de div. Mi desayuno favorito. H1. Y tenemos algunos hermanos para H1. Así que digamos que aquí tenemos un span y tenemos un botón. Vale. ¿Hay un reloj? Realmente no sé cómo voy con el tiempo. Pero eso está bien. No me muestres el reloj.

Entonces, bien, tenemos un H1. Y estos también tienen algo de texto debajo. Así que H1, digamos que esto es hola mundo así. El span, digamos que esto es una aplicación de contador donde estamos simplemente dibujando cosas. Y, por supuesto, digamos que esto es solo un contador unidireccional. Todo lo que puedes hacer es incrementar. Si pudiéramos hacer eso con mi salario, estaría realmente feliz. Genial. Así que este es un árbol de digamos elementos, digamos cinco, lo que sea, solo un árbol.

¿Cómo funciona el reconciliador de fiber? Ahora, en cualquier momento dado, el reconciliador de fiber mantiene dos árboles. Así que el paso uno, vamos a duplicar esto. Vamos a duplicar este árbol. Primero lo envolvemos en una bonita cajita, vamos aquí, y luego vamos a duplicar todo esto. Así que simplemente boom, segundo árbol, clon, vamos. Así que ahora tenemos dos árboles. El primero se llama el árbol actual, el segundo, vamos a llamarlo el árbol de trabajo en progreso. Y aquí es donde se hará mucho del trabajo de renderizado. Así que ahora la pregunta, ¿qué haría el reconciliador de fiber si yo hago clic en el botón de más e incremento el conteo? Eso es de lo que quiero hablar. ¿Y cómo lo hace? Así que hago clic en más. Lo que sucede es que trabajamos en el árbol de trabajo en progreso de una manera desconectada del entorno anfitrión, el navegador, hacemos cualquier actualización y luego la confirmamos. Y así es como sucede. Así que cuando hacemos clic en el botón, comenzamos el trabajo, por así decirlo. Y entonces llamas a begin work en el nodo más alto que es el main, y esto simplemente establecerá algunas flags, lo marcará como esto necesita actualizar o tal vez no. En este caso, no sé si lo hace porque su contenido está cambiando, pero de todos modos. Begin work establece algunas flags. Y cuando termina, se mete en el div, comienza el trabajo en el div. Lo mismo, marca cualquier actualización requerida. Solo dile a react cuál es el estado. Y luego cuando eso termina, entra en el hijo aquí, h1. Misma rutina. Comienza el trabajo, márcalo para actualizaciones, sigue adelante. Ahora, no hay hijos aquí. ¿Qué pasa? Completamos el trabajo. No hay hijos. No hay más hijos en los que entrar. Llamamos a una función llamada complete work y si no hay hermanos, volvemos al árbol. Si hay hermanos, vamos al hermano.

5. Entendiendo el Trabajo e Implementación de Fiber

Short description:

Completamos el trabajo en el árbol de fiber marcando el trabajo completo y moviéndonos al hermano. Después de completar el trabajo en los hijos, volvemos a la raíz. El trabajo completo construye un árbol desconectado de elementos DOM y conecta todo. El trabajo en progreso se pone en la pantalla usando el nodo raíz de fiber. Cuando el bucle de trabajo termina, cambiamos a la fase de compromiso, donde se ejecutan los efectos y se actualiza la UI. La implementación de Fiber se puede entender mirando el código y la estructura del árbol.

Completamos el trabajo aquí. ¿Cómo marco el trabajo completo? Simplemente voy a decir que el trabajo completo es volver por este camino. Y luego ir al hermano. Aquí al span. Comenzamos el trabajo en el span. ¿Tenemos hijos? ¿No los tenemos? Tenemos nodos de texto y esto probablemente está interpolado, así que esto cuenta como un hijo. Así que el trabajo inicial entrará allí, el trabajo completo porque no hay hijos, regresa, y simplemente caminamos. Caminamos, caminamos, caminamos. Y después de terminar con estos hijos, completamos el trabajo en los que aún no han completado el trabajo. Así que lo llamaremos trabajo completo y volveremos a la raíz. Ese es el ciclo.

¿Qué hace el trabajo completo? El trabajo inicial establece flags, el trabajo completo construye un árbol desconectado de elementos DOM, pero no en el navegador. Eso son props. Construye este árbol, construye, conecta todo. Y luego terminamos. Aquí es donde estamos. El siguiente paso es poner este trabajo en progreso en la pantalla. Para hacer eso, React tiene una estructura interna oculta llamada un nodo raíz de fiber. No ves esta cosa, pero existe. Y en el momento de montar tu aplicación, apuntará al árbol actual. Esto es antes de las actualizaciones. Este es el estado. Pero cuando el bucle de trabajo termina, cuando el trabajo completo termina en la última cosa, terminamos el trabajo de renderizado y cambiamos a la fase de compromiso. Nos comprometemos con el entorno anfitrión principal, el navegador, cambiando el puntero. Ahora eso es la fuente de verdad. Y también la fase de compromiso ejecutará cualquier efecto. Hay diferentes tipos de efectos. Hay efectos de host, que es literalmente como adjuntar los nodos dom al navegador. Hay efectos pasivos, que son tus llamadas a use effect y Así que los efectos se ejecutan, el nodo dom, tanto pasivo como de host efecto, todos se ejecutan en el compromiso y luego se actualiza tu UI. Así es como funciona Fiber. Por diagrama. ¿Genial?

¿Cómo funciona Fiber por código? Vamos, realmente no sé cómo voy con el tiempo. Simplemente miremos el código, lo que sea. No veo un reloj. Cuando enciendas un reloj, me detendré. ¿Cómo funciona esto en código? Abramos el código y lo que voy a hacer es literalmente abrir el código y haremos yarn parcel index. ¿Adivina qué? Construí esta aplicación de contador, esta de aquí, la construí como una demostración solo por diversión, ¿vale? Voy a abrir esto aquí y lo que tenemos es esto, que es literalmente lo mismo que esto. De hecho, si abrimos el código, ¿abrimos el código? Así que si abrimos el código, mira este árbol. Es literalmente main div, H1, span button. Es la misma estructura, ¿vale? Pero en código. Si has escrito React, esto parece familiar. Si lo abrimos ahora, está abierto. ¿Cómo lo abro? Vale. Esto funciona como se espera. Vamos a entrar en el código fuente de React DOM y jugar. Puedes decir que realmente no me gustan las diapositivas. Solo me gusta jugar. Así que lo que haremos es ir aquí. Literalmente nodo módulos. Uh-oh.

6. Explorando el Desarrollo de React DOM

Short description:

Vamos a profundizar en el desarrollo de React DOM. El código fuente está agrupado, pero es más fácil de leer en GitHub. Vamos a explorar el bucle de trabajo sincronizado y sus funciones. Perform unit of work almacena el estado y begin work envuelve otra función. La fibra actual se compara y nunca se modifica, mientras que la fibra de trabajo en progreso es con la que trabajamos.

Vamos a profundizar. ¿Dónde está react DOM? Ahí está. ¿Common JS? ¿Dónde está? React Desarrollo de DOM. Estamos aquí. Estamos aquí, todos. Hemos entrado. Mira esto. El número de regiones plegables está limitado a un máximo de 5,000. No es tan complejo. Está simplemente agrupado. El código fuente es mucho menos agrupado para las cosas. Es más fácil leer el GitHub.

Queremos empezar con el bucle de trabajo sincronizado. Eso es lo que teníamos en nuestro diagrama. Vamos a buscar con el comando F. Lo tenemos. ¿Qué hace esta función? Vamos a la definición. Así que mientras haya trabajo que hacer, hazlo. Es declarativo. Me encanta. ¿Qué hace eso? Vamos más profundo. Es como el tema del pez. Este pez, queremos encontrar el pez. Si crees eso, tuitea 'encuentra el pez'. De todos modos, perform unit of work. ¿Qué hace esto? Almacena algún estado. Si estamos en modo de perfil. No estamos en modo de perfil. Estamos en begin work. Vamos más profundo. ¿Qué es begin work? Es una función que envuelve a otra función. Vamos a esta. Begin work. Hemos llegado a la zona. Hay tres argumentos. Ese es el del entorno anfitrión. No tocamos esto. Lo pasamos alrededor. La fibra actual es la que enviamos aquí, la que enviamos allí. La comparamos. Nunca la modificamos. No es. Pero la fibra de trabajo en progreso es con la que trabajamos porque está en progreso. Así que empecemos por console. Log. Veamos una fibra. Todos, están a punto de ver una fibra. Trabajo en progreso. Hagámoslo. Ahora abramos esto.

7. Entendiendo Begin Work y Complete Work

Short description:

Vaya a la consola. Estamos trabajando en el nodo raíz de la fibra, que es la cosa oculta de la que hablamos. Begin work compara las viejas props con las nuevas props o los cambios de contexto y establece flags para las actualizaciones. Complete work sigue un proceso similar, y completamos el trabajo en el nodo raíz de la fibra.

Vaya a la console. Bueno, ahí lo tenemos. Permítanme aumentar el tamaño de la fuente para ustedes. En qué. El nodo de estado es en lo que estamos trabajando. Así que estamos trabajando en el nodo raíz de la fibra. Eso es esa cosa oculta de la que hablamos en el diagrama. Comenzamos a trabajar un nivel más bajo en el componente de la aplicación, uno más bajo en main. Así es como se ve una fibra, por cierto. El nodo de estado es el elemento real que es mutable. El nodo mutable. Puedes ver literalmente comenzar a trabajar y recorrer el árbol. Así que main, div, span. Comienza a trabajar bajando. Y veamos qué hace realmente begin work. Así que esto es una cosa interna de debug. No hablaremos de eso. Pero si el nodo actual no es nulo, es decir, si el nodo actual en el entorno del host existe, entonces ¿qué? Es una actualización. No una inserción. ¿Okay? Así que en el camino de la actualización, esto es lo que hace begin work. Comparamos las viejas props con las nuevas props o si ha cambiado el contexto. Establecemos algunas flags. Y si desplazo, solo estamos estableciendo flags, asegurándonos de que el reconciliador sabe que esto necesita actualizar o no necesita hacerlo. Eso es todo. A medida que desplazamos hacia abajo, tenemos un enorme switch case para diferentes tipos de componentes, componentes perezosos, componentes de función, componentes de clase, límites de suspense, etc., que simplemente los marca como que esto necesita actualizar. A medida que desplazamos más allá del gran switch case, eventualmente terminamos en un throw donde la unidad dice que no sabe qué estás tratando de hacer, pero no puede trabajar en esto. Y eso es begin work. Ahora veamos complete work. Volvamos a subir el árbol. Complete work, como notarás, la misma firma, render lanes es una preocupación de programación que está fuera del alcance de esta masterclass, así que no abordaremos eso. Todavía tenemos la fibra actual , la fibra de trabajo en progreso. Por posteridad, registremos este trabajo en la fibra de complete work . Y simplemente haremos un console log de la fibra de trabajo en progreso aquí. Y ahora cuando esto se recargue, veremos, oh mira, se volvió más complejo. Así que begin work. Begin work. Seguimos comenzando a trabajar hasta que llegamos a H1, ¿verdad? Ahora H1 no tiene hijos. H1 es un hermano. Si miramos el árbol DOM aquí, H1, no más hijos. Un nodo de texto, pero eso no es un elemento. Es solo texto. Así que comenzamos a trabajar en H1. Como puedes ver aquí, tipo de elemento H1. Y lo completamos de inmediato. Comenzamos a trabajar en el span, pero noten que hay más hijos aquí, porque eso es porque tengo esta interpolación aquí. Okay, así que se tratan un poco diferente. Pero comenzamos a trabajar, y si no hay hijos, completamos el trabajo. Y finalmente completamos el trabajo en el botón, el div, el main, el componente de la aplicación. Por último, también completamos el trabajo en el nodo raíz de la fibra. Y luego, aquí puedes ver, el nodo de estado es la fibra

8. Entendiendo Complete Work y la Fase de Compromiso

Short description:

Exactamente. Eso es esa cosa invisible. Ese switch es un puntero. Un componente de host es un componente en el entorno del host. Para React DOM, el entorno del host es el DOM. En un componente de host, propagas propiedades. Complete work construye el nodo DOM, lo adjunta al padre, lo mueve de nuevo hacia arriba. Luego cambiamos a la fase de compromiso llamando a commit root, que vacía los efectos pasivos y cambia el puntero.

nodo raíz. Exactamente. Eso es esa cosa invisible. Ese switch es un puntero. Así que hemos mirado, veamos qué hace complete work. Así que si volvemos aquí, es un enorme switch case de nuevo. ¿Verdad? Para todos estos tipos de componentes, propagar propiedades. Y eso es exactamente lo que suena. Y quiero centrarme aquí en una cosa específica llamada el componente de host. Un componente de host es un componente en el entorno del host. Para React DOM, ¿cuál es el entorno del host? Es el DOM. El navegador. En un componente de host, ¿cómo completas el trabajo? Así es como. Propagas propiedades. Verificas si fue hidratado desde server side rendering. Pero en este caso, no es así. Solo estamos en el lado del cliente renderizando. Cambiaremos a la otra rama. Ve aquí. Y la instancia es create instance. ¿Sabes lo que es eso? Vamos un nivel más profundo. Create instance es esencialmente un documento que valida algunas anidaciones y llama a create element. Y ahora estamos en lo que hace complete work. Básicamente está creando un elemento fuera, como separado de el navegador, pero aún está construyendo un árbol. Complete work construye el nodo DOM, lo adjunta al padre, lo mueve de nuevo hacia arriba. Vale. Solo recorre el árbol. Y puedes ver eso. Añadimos todos los hijos, establecemos el nodo de estado en la instancia, y marcamos algunas actualizaciones, etc., y simplemente seguimos en el switch case. Complete work finalmente llega a la raíz y la renderización ha terminado. Luego cambiamos a la fase de compromiso. Ponemos cosas en la pantalla. Cambiamos. Si volvemos al diagrama, lo que es la fase de compromiso, si recuerdas, es cambiar el puntero, así. ¿Cómo cambiamos el puntero? Hay una función llamada commit root. Sí, esa es. Vamos a profundizar en esto y ver. Lo que quiero hacer es console.log, commit root. Y registraremos la raíz aquí, pero preferiblemente así. Guardar. Así que ahora ves, hemos comprometido la raíz. Literalmente solo cambia el puntero. Este es el nodo raíz de la fibra que estás viendo. Cada vez que llamo a esto, simplemente hace lo mismo una y otra vez muy, muy rápido. ¿Qué hace commit root? Vacía los efectos pasivos. Un efecto pasivo, mira, hay incluso una explicación aquí. Un efecto pasivo no es un efecto de host No es como adjuntar cosas al DOM. En los efectos de host, hay diferentes tipos. Hay un efecto de inserción, hay un efecto de colocación, hay un efecto de actualización, estos efectos literalmente implican mutar el DOM y hay efectos pasivos que son efectos de componente cero. Así que vaciamos esas cosas, marcamos algunos eventos, y finalmente cambiamos el puntero aquí.

9. Internos de React y Entendiendo el Código

Short description:

Así que simplemente ejecutamos, hay muchos efectos en ejecución, realmente, muchos efectos se están confirmando. Pero en algún momento verás que cambiamos los árboles del actual al trabajo en progreso. Los internos de React son complejos, pero los externos son poderosos debido a eso. Entender los internos me ha ayudado en casos de revisiones de solicitudes de extracción donde tenemos debates o algo. Me alejo de las micro-optimizaciones porque sé lo que está pasando. Ayuda a informar cuánto optimizo.

Así que simplemente ejecutamos, hay muchos efectos en ejecución, realmente, muchos efectos se están confirmando. Pero en algún momento lo que verás es que cambiamos los árboles del actual al trabajo en progreso. Y también llamamos a un hook. Cuando termina, ¿qué pasa? Eventualmente, marcamos la confirmación como detenida, y termina donde terminan todas las últimas cosas. Así que lo que quiero mostrarte con esto es, uno, cómo funciona con el bucle, pero también que hay muchos casos límite, hay muchas cosas que React resuelve por ti que no necesitas resolver tú mismo, y esa es toda la propuesta de valor, ¿cómo hacemos actualizaciones a la UI de una manera rápida, de una manera predecible, y de una manera que nos permite simplemente construir aplicaciones rápidas, sin preocuparnos demasiado con los internos. ¿Eso está bien? Muy bien. Hablemos de mi conclusión. ¿Qué podemos llevarnos de esta charla? Podemos llevarnos que los internos de React son complejos, pero los externos son poderosos debido a eso. Como, podemos construir todos esos casos límite, esos grandes switch cases que viste, nuestro trabajo que el equipo hace en nuestro nombre, para que no tengamos que hacerlo, para que React pueda tener un ambiente realmente bueno para construir aplicaciones de manera poderosa y rápida. Dicho esto, los internos son divertidos. Y mi única conclusión para ti es recordar, oye, escucha, React, he oído a mucha gente decir que React es demasiado difícil o demasiado complejo, como los internos. Toda esta charla que preparé fue leyendo el código fuente en GitHub porque es de código abierto y tratando de participar, y de hecho, ahora estoy participando, supongo, hablé con algunos del equipo que son muy acogedores y de apoyo, y es un ecosistema. Así que mi conclusión es, estoy agradecido de ser parte de este ecosistema y espero que te sientas alentado a hacerlo también. React Advanced London, gracias muchísimo por el tiempo. Gracias, gracias, gracias. Por favor, deja tu portátil y sígueme a la sala de interrogatorio. Uh-oh. Sí. Estoy a punto de ser interrogado. Estás en problemas, joven. No, gracias, eso fue una inmersión profunda. Realmente estás cumpliendo con tus promesas y el nombre de esta conferencia. ¿Soy un pez? ¿Eres un pez? ¿Quieres ser un pez? ¿Ser un pez es algo bueno? Hay un superhéroe en este show llamado The Boys que es un pez. The deep, de todos modos. Sí, yo, Aquaman está infravalorado es mi opinión. Esa es mi opinión. ¿Deberíamos hablar más de eso? No, está bien. Vamos a las preguntas de la audiencia. La primera pregunta de la audiencia es, ¿de qué manera has descubierto que una comprensión más profunda de React bajo el capó ha informado o cambiado el código que escribes? Me gusta mucho esto. Me gusta mucho esto. Así que en pequeñas formas. Y no puedo enfatizar lo suficiente cuán importante es no preocuparnos demasiado con los internos. Hay personas bien pagadas para hacer eso por nosotros, ¿verdad? Y así lo hacen bien por nosotros para que no tengamos que hacerlo, y el enfoque es usar React. Y ese es el enfoque. No necesariamente entender los internos. Pero entender los internos me ha ayudado en casos de revisiones de solicitudes de extracción donde tenemos debates o algo, podemos realmente mirar el código y puedo enseñar y mentorizar. Creo que ayuda. Pero también, me alejo de las micro-optimizaciones porque sé lo que está pasando. Como, no necesito poner todo en used memo. No necesito hacer todos mis componentes perezosos. Como, ayuda a informar cuánto optimizo porque sé cuánto se está optimizando para mí detrás de las escenas, así que. Por supuesto. Quiero añadir mi propia pregunta a eso. Recuerdo cuando solíamos trabajar con herramientas más sencillas que no eran tan poderosas, pero también eran más sencillas. En un momento, creo que recordaba la mayor parte del código fuente de backbone de memoria. Ahora con estas herramientas que usamos ahora, la complejidad es demasiado para un programador de producto en funcionamiento para mirar. Entonces, ¿cuánto crees que es importante a medida que te vuelves, digamos, más senior en la organización tener a una persona en el equipo que entienda estas herramientas? ¿O es simplemente una pérdida de tiempo? No sé si es una pérdida de tiempo, porque creo que una parte importante de ser un ingeniero senior es la capacidad de mentorizar. Hay una sala de habilidades blandas, ¿verdad? Realmente quiero asistir a eso porque siento que eso es en realidad más importante que el código en sí a veces. Y así creo que si hay al menos una persona que tiene un verdadero conocimiento profundo allí, pueden usarlo para educar e informar. Y hay muchos patrones en esta base de código de los que puedo aprender personalmente.

10. React 18 y el Bucle de Trabajo

Short description:

Las funciones de bucle de trabajo sincrónico y bucle de trabajo asíncrono en React 18 facilitan las características concurrentes y un sistema de prioridad. Aunque el código mostrado todavía está en React 18 y no ha cambiado, el bucle de trabajo asíncrono puede convertirse en el predeterminado en el futuro. Si un elemento se elimina directamente a través del objeto del documento, puede provocar problemas con el reconciliador de React. Se recomienda utilizar refs en su lugar. XcaliDraw es la herramienta de dibujo utilizada, pero existen otras alternativas excelentes como tlDraw y stately.ai.

Solo por ejemplo, ¿verdad? Esta función llamada bucle de trabajo sincrónico. Mientras haya trabajo por hacer, hazlo. Esta forma de estructurar code es algo que puedo aprender y luego enseñar a mi equipo. Así que no creo que sea inútil. También creo que si eres una empresa en esta economía, es algo bueno de tener. Pero no creo que sea obligatorio. Genial. La siguiente pregunta más votada es, ¿cambió algo en este algoritmo React 18? Esa es una buena pregunta. Lo que estaba usando, estoy bastante seguro, era React 18. ¿Es React 18 la última etiqueta? Eso era React 18, así que no tal vez, pero hay un... Así que había un bucle de trabajo sincrónico del que hablé. También hay un bucle de trabajo asíncrono. Esa es la característica concurrent. Y eso utiliza, hasta donde yo sé, esto es donde se vuelve incierto, pero eso utiliza un programador bajo el capó que literalmente calculará cuál es una actualización de alta prioridad, cuál no, y todo el punto de Fiber es ser interrumpible. Así que cambiar de bucle de trabajo sincrónico a bucle de trabajo asíncrono facilitará muchas de estas características concurrent donde ahora hay un sistema de prioridad y un programador para esos. El code que mostré todavía está en React 18 y no ha cambiado, pero en algún momento, sospecho, el bucle de trabajo asíncrono será el predeterminado y el bucle de trabajo sincrónico será la opción de respaldo. Sí, esperemos que el próximo año podamos tenerte de vuelta y puedas dar una charla sobre el programador asíncrono. Sí. Creo que esa es la parte para mí que todavía es un poco de magia negra. Entiendo que funciona, pero no estoy realmente seguro de cómo en absoluto. Me está dando ideas para mi próxima charla. ¿Quieres ver eso? No. No. Yo tampoco. Yo tampoco. Pero ese era ese chico. Deberías hablar con él después. Sí. Muy bien, pregunta principal. Vamos por orden democrático. Esto parece casi como una pregunta de entrevista de trabajo. Si un elemento es eliminado por un objeto de documento directamente, así que asumo que manipula el DOM, ¿existe la posibilidad de causar una fuga de memoria ya que el Fibre mantiene la referencia? No sé cómo Fibre mantiene las referencias. No he investigado eso, pero sí. Conoces el reconciliador de pila antes del Fibre. Así es como solía ser, ¿verdad? Las cosas se mutan sobre la marcha. El problema con eso es que no puedes abandonar algo a mitad de camino. Si solo actualizas la mitad del DOM, y dices, llegó una actualización de mayor prioridad, ¿qué haces? No puedes revertirlo. ¿Deberías revertirlo? No puedes. Así que se complica. Así que si un elemento es eliminado a través del objeto del documento directamente, básicamente vuelves a React como pre-16, que hay una razón por la que eso fue deprecado. Y creo que si el elemento es mantenido por React mismo, creo que el próximo bucle de trabajo será añadido o se bloqueará de una manera indefinida. Así que probablemente sea una mala idea, y no deberías hacer eso. Usa refs. Sí. Esa es parte del trabajo completo, así como la actualización de refs. Genial. Pregunta principal, por supuesto, no qué fuente usaste, sino ¿cuál es el nombre de la herramienta de dibujo que usaste? XcaliDraw, lo usé porque me gusta, pero grandes alternativas, tlDraw, gran herramienta. Sí, tenemos un tl, y también stately.ai para diagramas. Excelente. Realmente, no nos faltan herramientas increíbles aquí.

11. Diferencias y Beneficios de Fiber

Short description:

Fiber aporta varias diferencias sobre las antiguas heurísticas de reconciliación. Permite la renderización asíncrona, la programación y la capacidad de hacer trabajos a medias y descartar árboles de trabajo en progreso. Esto no era posible con el reconciliador de pila anterior, que a menudo causaba que las actualizaciones de baja prioridad bloquearan la entrada del usuario.

Genial. Tenemos tiempo para una o dos preguntas más. Permíteme tomar esta. ¿Qué diferencias aporta Fiber sobre las antiguas heurísticas de reconciliación? Quiero decir, supongo que la capacidad de hacer renderización asíncrona y todo eso es algo del futuro, pero ¿hay algo más que te gustaría añadir? Creo que la programación, realmente. Esto es algo grande. Como, la capacidad de hacer trabajos a medias y luego descartar un árbol de trabajo en progreso, eso es genial. Nunca podrías hacer eso antes. No había forma de hacer trabajos a medias, y entonces, porque no podías hacer trabajos a medias de la manera anterior, el reconciliador de pila, que creo que es la pregunta. Olvidé la pregunta. Estoy improvisando. No puedes hacer trabajos a medias, así que lo que sucedería era una actualización de muy baja prioridad, como alguna cosa de imagen que quizás no era importante bloquearía un problema de entrada del usuario. Y luego Dan Abramov dio esta charla en JSConf Iceland sobre CPU-bound y I O-bound, y yo estaba como, guau, eso es increíble. En fin. Genial. Bien. Hagamos una pregunta final. Creo que tenemos un par de preguntas sobre el mismo tema. Creo que esta es una pregunta muy razonable dado el cambio general de terminología. Entonces, ¿cómo encaja el concepto de DOM virtual en este tipo de cosa de Fiber? ¿Es Fiber el DOM virtual? ¿Cuál es la relación entre estos dos términos? Esa es una buena pregunta. Hasta donde yo sé, conocimiento falible. Hasta donde yo sé, el DOM virtual es solo un virtualizado... es solo como una data estructura. Es solo un... es una representación clonada de tu DOM pero para que una biblioteca haga lo que quiera con él y luego, ya sabes, seguimiento de cambios y diferenciación y todo eso es aparte hasta donde yo sé. Genial. Bueno, eso es todo el tiempo que tenemos para el escenario. Pero cualquiera que quiera hablar con Tejas puede encontrarlo en los pasillos o en la sala de preguntas y respuestas de los oradores donde también puedes unirte a través del chat espacial si nos estás acompañando de forma remota. Muchas gracias, Tejas. Demos a Tejas un último gran aplauso.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

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

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

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

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.