¡Espera, ¿React es multi-hilo?

Rate this content
Bookmark
Slides

Ya sabemos, "si alguna tarea lleva tiempo, prometifícala". Pero algunas tareas pueden ser intensivas en cálculos y llevar tiempo en completarse, por lo que hacerlas asíncronas no sirve de nada ya que de todos modos deben ser seleccionadas. ¿Solución? ¡Simple, multihilo! Sí, sé que React y, en consecuencia, JavaScript son de un solo hilo, pero ¿qué pasaría si te dijera que nuestra vida ha sido una mentira desde siempre? ¡Ingresa a los web workers! Puntos clave de la charla: 1. Un ejemplo de una búsqueda simple de productos que muestra por qué el js asíncrono o el modo concurrente no pueden funcionar. 2. Desmitificando los web workers. 3. ¿Cómo hacen esta magia bajo el capó? 4. La pregunta de la vida: ¿no son lo mismo que el modo concurrente? 5. Comparando la misma aplicación de lista de productos usando web workers, adentrándonos en el rendimiento. 6. Cómo se pueden usar incorrectamente los web workers y cómo evitarlo.

22 min
05 Dec, 2022

Video Summary and Transcription

Esta charla explora el uso de los web workers en React para mejorar la experiencia del usuario y el rendimiento. Se discuten las limitaciones del renderizado de JavaScript y cómo los web workers pueden descargar tareas en hilos separados. La charla también destaca los beneficios de usar el modo concurrente en React e introduce la biblioteca UseWebWorkerHook para simplificar la creación de web workers. Se enfatizan las consideraciones al usar web workers y concluye con una mención de las contrataciones y el lanzamiento de nuevas funciones de Postman.

Available in English

1. Introducción y Antecedentes

Short description:

Soy Nikhil, un ingeniero en Postman, especializado en sistemas de diseño y rendimiento a gran escala. Conéctate conmigo en Twitter y GitHub.

¡Hola a todos! Gracias por la increíble presentación. Estoy muy contento y emocionado de estar aquí virtualmente en React Berlin y poder compartir mis pensamientos con todos ustedes. Como probablemente ya se dieron cuenta, soy Nikhil y trabajo como ingeniero en Postman. Principalmente me ocupo de cosas relacionadas con los sistemas de diseño, Postman en la web y la plataforma de escritorio de Postman. Así que si quieres hablar conmigo sobre rendimiento de los sistemas de diseño a gran escala en general, me encantaría hablar de eso, por cierto. Así que ven y saluda. Me encantaría conectarme en Twitter, en GitHub. Creo que podrás ver las etiquetas relevantes y cómo puedes contactarme. Así que nos encantaría tener una charla.

2. React Multi-Threading and User Experience

Short description:

En esta sesión, responderé a la pregunta de si React puede ser multi-threaded y cómo puede mejorar la experiencia del usuario. Las aplicaciones de carga lenta y no responsivas pueden hacer que los usuarios se vayan. Entendamos el problema a través de una demostración y analicemos la causa raíz del problema, que involucra el bucle de eventos y tareas de larga duración.

De acuerdo. Antes de sumergirnos en la presentación, me gustaría dar una breve descripción de lo que voy a hablar aquí. En esta sesión, intentaré responder una pregunta muy simple, que es si React puede ser multi-threaded o no. ¿Tiene capacidades de multi-threading y cómo puede ayudarnos a mejorar la experiencia del usuario? Comencemos con una afirmación muy noble, que es que la experiencia del usuario es importante, ¿verdad? Lo que realmente significa una buena experiencia del usuario es que es muy agradable para los usuarios utilizar diferentes partes de sus aplicaciones, como diferentes funciones, con una experiencia fluida. No tienen que buscar cómo hacer algo. No tienen que esperar, cosas así. ¿Verdad? Una buena experiencia del usuario siempre es beneficiosa para tu producto y para generar negocio, ¿verdad? Porque los usuarios siempre están contentos si tu producto es fluido.

Para hablar de esto en extensión, se realizó una encuesta que mostró varias razones por las que los usuarios abandonan una aplicación. Si observas estas diversas razones, una de las principales razones fue la carga lenta, lo cual significa que el 88% de los usuarios sienten que no quieren usar tu producto si se carga muy lento, pero no queremos hablar de eso en nuestra sesión. Lo que queremos enfocar más en esto es este círculo amarillo que ves, que es el 73% de los usuarios que no utilizan una aplicación o la abandonan porque no responde o es muy lenta. Y sabemos que una buena experiencia del usuario siempre es beneficiosa para tus usuarios, como mencioné, ¿verdad? En este caso, si te encuentras en alguna de estas categorías y la experiencia del usuario no es buena, tus usuarios podrían abandonar la aplicación o no querer usarla. No quieres que tengan una experiencia así, ¿verdad? Siempre quieres que estén contentos. Y esto es de lo que queremos hablar en nuestra charla.

Intentemos entender el problema rápidamente y mostrarte qué tipo de problema estoy hablando. Si voy a la demostración, verás esta pequeña aplicación que muestra un bonito spinner de React que gira para mostrarte cuándo se vuelve no receptiva nuestra aplicación. Hay una gran lista de elementos y no hay nada especial en ella. Son solo algunos elementos que quiero ordenar. Inicialmente, he mantenido la lógica de ordenamiento muy lenta, que es el ordenamiento de burbuja en este caso, y que tiene la intención de mostrarte la experiencia de una UX deficiente y lenta al realizar una tarea que es muy grande. Si hago clic en este botón, que es la forma antigua de hacerlo, voy a realizar un ordenamiento en esta gran lista de elementos. Y dado que esa tarea va a llevar mucho tiempo, veamos qué le sucede a la experiencia del usuario en esa aplicación, ¿verdad? Hago clic en este botón. Ahora mi aplicación está completamente congelada. No puedo hacer nada. No puedo hacer clic en los botones. Y esto es muy malo. Después de un tiempo, cuando se completa la tarea, el spinner vuelve a girar, lo que significa que durante un tiempo mi aplicación estuvo completamente bloqueada. Este es realmente el problema.

Ahora intentemos hacer un análisis de la causa raíz de lo que salió mal y qué se podría haber mejorado al construir este tipo de experiencia. Veamos un diagrama muy simple que muestra el funcionamiento actual de nuestro bucle de eventos. Nuestro bucle de eventos consiste en tu código JavaScript, tu bucle de eventos es como una pila, o no exactamente una pila, simplemente toma cierta cantidad de operaciones, ya sean algunas funciones de JavaScript, ya sean otros eventos, como eventos de mouse, eventos de clic, y los atiende uno por uno, ¿verdad? Y si hay algún evento que es muy grande, en ese caso nuestro bucle de eventos se bloquea por completo. Y tus usuarios no pueden hacer nada más debido a esta tarea de larga duración, ¿verdad? Y dado que tu bucle de eventos está ocupado y tu JavaScript tarda demasiado tiempo en liberarse, tu interfaz de usuario parecerá completamente congelada y tus usuarios no podrán hacer nada hasta que se complete o no esta gran tarea.

3. JavaScript Rendering and Web Workers

Short description:

Para mejorar la experiencia del usuario, es importante asegurarse de que JavaScript se ejecute y renderice los fotogramas dentro del tiempo asignado. Si JavaScript tarda más, es posible que se omitan los fotogramas siguientes, lo que resulta en una experiencia deficiente. Para solucionar esto, se pueden utilizar los web workers para desviar las tareas más grandes a hilos separados, permitiendo que el hilo principal permanezca desbloqueado. Al crear una instancia de worker y enviar mensajes al hilo del worker, se pueden ejecutar tareas en paralelo, mejorando el rendimiento.

Entonces ese es el problema exacto, es este evento muy grande que está llegando. Para respaldar mi afirmación, hagamos un cálculo rápido de cómo todo esto se alinea en un lugar central, ¿verdad? Si ves ese spinner en nuestra demostración que mostramos, ¿verdad? Si quieres que se haga a 60 fotogramas por segundo, eso significa que tendríamos mil milisegundos para renderizar 60 fotogramas, ¿verdad? Esa es la matemática. Y significa que tienes 16 milisegundos para que se ejecute tu JavaScript por fotograma.

Ahora, para hablar más realistamente, los navegadores suelen tomar cuatro o seis milisegundos de estos 16 milisegundos, que son sus tareas internas, composición, pintura, comprensión de cómo analizar HTML, JavaScript y cosas así. Entonces, aproximadamente, si hablamos de ello, tu JavaScript en realidad solo tiene de 10 a 12 milisegundos o menos para ejecutarse y renderizar ese fotograma en un tiempo constante y evitar el retraso.

Ahora, intentemos ver este pequeño ejemplo de cómo tu código realmente pasa por el pipeline del navegador, qué exactamente va a suceder cuando se ejecute tu JavaScript, cuando se ejecute tu CSS y cuando todo se compile. Todo esto, si lo ves en un fotograma, todo esto debe hacerse en 16 milisegundos o menos tiempo. Tu navegador tiene que ejecutar JavaScript, tiene que calcular cuáles son los estilos, cuál es el CSS para ello, tiene que renderizar todo el CSS, preparar el DOM, tiene que componer todo y analizar todo y mostrar el resultado final en tu página web. Ahora, a medida que sigues agregando más JavaScript, no solo estamos usando JavaScript básico en este momento. Tal vez estemos usando un motor CSS y JS como Style Components, tal vez estemos usando Redux o una biblioteca llamada React. Sin mencionar que React, agregar React puede agregar tiempo a la ejecución de tu JavaScript. Pero la intención detrás de este ejemplo es que cuanto más tiempo tome tu JavaScript, más tiempo se extenderá para que tu navegador se ponga al día con esto. Porque todo esto debe hacerse en 16 milisegundos. Si tu JavaScript está tardando más tiempo, superarás ese límite de 16 milisegundos. Y debido a eso, como mencioné, necesita omitir los fotogramas. Y eso es exactamente lo que es un tartamudeo, porque solo ves un spinner que no se mueve, porque tuvo que omitir todos los fotogramas para ponerse al día con la velocidad, ¿verdad? Y ese fue exactamente el problema allí.

Ahora, volviendo al problema, que era una tarea muy grande que estaba bloqueando tu bucle de eventos, ¿verdad? Ahora, si tuviera que sacar esto de mi bucle de eventos y evitar que se bloquee, mi problema se resolvería, ¿verdad? Entonces, las otras tareas más grandes pueden seguir ejecutándose en algún contexto separado, mientras mi bucle de eventos está completamente libre. Entonces, cualquier tarea más grande no está bloqueando mis páginas web, la experiencia del usuario o no está entorpeciendo la experiencia. Y esta es exactamente la ideología de un web worker, ¿verdad? En resumen, los web workers nos permiten realizar trabajos en paralelo utilizando hilos separados, ¿verdad? Esa es la analogía más simple. Entonces, puedes hacer más cosas en algún contexto paralelo o en hilos paralelos para evitar que tu hilo principal se bloquee, ¿verdad? Y puedes asignar todas esas tareas más grandes a tus hilos de trabajador.

Ahora, si quiero mostrarte cómo funciona todo esto, ¿verdad? Entendamos la pequeña analogía. Hay tu aplicación React que se ejecuta en un hilo totalmente diferente. Y hay un hilo de trabajador que, nuevamente, es un contexto totalmente separado. Ahora, lo que sucede es que creamos una instancia de trabajador utilizando la nueva API de trabajadores. Y el trabajador que obtenemos, adjuntamos, enviamos un mensaje a nuestro hilo de trabajador, lo cual se hace mediante la API worker.postMessage. Entonces le enviamos un mensaje que dice: `Oye, hay esta tarea grande que necesitas hacer`. Y el trabajador lo recibe porque adjuntamos un event listener en el lado del trabajador, que es self.eventlistener. Asegúrate de que los trabajadores no tengan acceso a tu ventana.

4. React Workers and Resource Management

Short description:

El hilo principal de React no se bloquea mientras los trabajadores manejan la tarea grande. El trabajador envía un mensaje de vuelta a la aplicación de React cuando ha terminado, y el resultado se muestra en la interfaz de usuario. Para liberar recursos, se termina el trabajador.

Solo tiene acceso a un objeto global llamado this, ¿verdad? Entonces, en el event listener, escucha eso, oh, React me está diciendo que haga algo. Permíteme hacer ese trabajo. Y mientras tanto, el hilo principal de React no está bloqueado porque toda la tarea grande la están realizando los trabajadores. Y si se completa a tiempo, el trabajador envía un mensaje nuevamente a tu aplicación de React. Y tu aplicación de React vuelve a escuchar que, oh, ahora el trabajador ha completado algo, y hacer algo en mi interfaz de usuario para mostrar si está hecho o no. Y luego se muestra el resultado en la aplicación de React. Y finalmente, cuando todo está hecho, también queremos liberar todos los recursos de los usuarios porque un trabajador también está utilizando los recursos del usuario para ejecutarse como un hilo separado, por lo que hacemos worker.terminate, que es una buena práctica.

5. Concurrent Mode and Web Workers

Short description:

En el modo concurrente, React puede alternar entre tareas prioritarias, lo que da la sensación de paralelismo pero en realidad utiliza el cambio de contexto. JavaScript es de un solo hilo, pero los web workers pueden ejecutarse en núcleos de CPU separados, lo que permite una funcionalidad similar a la de múltiples hilos. Sin embargo, existen bloqueadores para utilizar los web workers fácilmente, como la compleja comunicación de mensajes y coordinación entre los workers. Las promesas pueden ser una solución, ya que permiten una detección más sencilla de la finalización y actualización de la interfaz de usuario. Una biblioteca que puede ayudar con esto es Commlink.

Ahora, la pregunta del millón, ¿todo se hace mediante el modo concurrente? Porque también maneja cosas como hacer tareas que llevan más tiempo o un contexto similar, como los web workers. ¿Qué hacen los web workers que es diferente de esto? Así que si te hago un breve resumen de lo que era el modo concurrente, si imaginas que hay una aplicación de búsqueda de productos donde escribes algo y la lista de productos se actualiza según tu consulta de búsqueda. Muestra que hay un evento del usuario, como escribir, y hay una fase de renderizado donde la aplicación React debe actualizar tu interfaz de usuario según la búsqueda que hiciste. Y esa fase de renderizado, que es esta franja amarilla muy grande, es ininterrumpible. Porque React no tenía la capacidad de saltar a una tarea específica de prioridad, que era manejar ese evento del usuario antes de hacer la parte de renderizado. En el nuevo modo concurrente, esta franja amarilla se puede dividir, lo que significa que React puede volver atrás, pausar su renderizado e ir a una tarea de prioridad diferente, que era un evento del usuario. Para atender eso, mostrar que la escritura funciona bien y luego reanudar su renderizado. Si entiendes esta analogía del modo concurrente, la diferencia radica en el paradigma en sí, que es el modo concurrente en primer lugar, que es el cambio de contexto. Está haciendo la misma tarea, pero está creando sub tareas a partir de ellas y está alternando entre los contextos. Así que parece que es paralelismo, pero en realidad es solo cambio de contexto y está haciendo la tarea de manera sincrónica.

En cambio, el paralelismo en general no es en sí mismo cambio de contexto, es como utilizar diferentes recursos de tu CPU para realizar diferentes tareas. En el primer ejemplo, solo estoy haciendo una tarea. Pero en realidad, el paralelismo puede realizar cualquier número de tareas en paralelo. Otra pregunta que surge ahora es, ¿cómo haces multihilo incluso si es posible? Porque JavaScript en sí mismo es de un solo hilo, ¿verdad? ¿Cómo puedes hacer esto? Así que necesitamos entender el hilo y la CPU como dos entidades diferentes para entender mejor esa respuesta. Un hilo es una entidad totalmente diferente. Un núcleo de CPU, que puede abrir un hilo, es un juego de pelota totalmente diferente. Como puedes ver, antes nuestras máquinas solían ser de un solo núcleo. Pero ahora, en la nueva era de las computadoras, tienes máquinas multinúcleo, ¿verdad? Entonces, lo que queremos hacer es que nuestra aplicación React se ejecute en un núcleo de CPU totalmente separado, ¿verdad? Nuestro web worker, que nuevamente es algo de un solo hilo, pero se está ejecutando dentro de un núcleo de CPU totalmente diferente. Lo que significa un contexto de ejecución totalmente diferente, y todos están trabajando en términos de pasarse mensajes entre sí para comunicarse cuando se haya completado el trabajo. Así que es de un solo hilo, pero algo así como multihilo, ¿verdad? Así que entiendes por qué funciona como algo multihilo. Así que estamos utilizando los recursos de los usuarios de diferentes núcleos y estamos ejecutando estos dos mundos diferentes por completo fuera de estos núcleos. Dado que esto aporta mucho, ¿por qué no lo usamos?, es la siguiente pregunta. Personalmente descubrí que hay muchos bloqueadores que nos impiden usar los web workers de manera más sencilla. Si ves, un ejemplo es que tienes un web worker, pero tienes que crear una instancia de comunicación de mensajes en él, ¿verdad? Tienes que crear, tienes que configurar escuchadores de eventos y tus workers y tu aplicación principal de React tienen que escuchar para pasar escuchadores de eventos a él, lo cual es como un código adicional que no me gusta. En cambio, ¿no habría sido mejor que solo necesitaras crear una función dentro de tu worker y cuando crees una instancia del worker en el hilo principal, simplemente haces worker.esa función que creaste, lo cual es mucho más simple, ¿verdad? Otra clase de problema que vi es cómo saber cuándo se completa el hilo del worker o no, como saber el estado, ¿sigue ejecutándose? ¿Ha comenzado o no? ¿Está hecho o no? Eso es totalmente, diría que es muy difícil de hacer, porque son mensajes que se envían y se olvidan. Así que no hay una forma directa de saber cómo actualizar tu interfaz de usuario en función de cuándo se va a completar este worker. Una extensión de este problema es en realidad una de las otras cosas clave que descubrí, que es cómo coordinar entre los web workers, ¿verdad? Porque si ves en este ejemplo, hay un worker que está haciendo una tarea, hay otro worker que está haciendo alguna otra tarea. Y luego hay un tercer worker que en realidad está esperando a que se completen la primera y la segunda tarea, ¿verdad? Es como, la complejidad aumenta cuando estás usando este tipo de arquitectura y manejas demasiados web workers alrededor de eso, ¿verdad? Entonces, ¿cuál podría ser la solución? Obviamente, las promesas, ¿verdad? Porque el JavaScript asíncrono es tan fácil de detectar cuándo algo va a completarse, ¿verdad? Sería un poco más fácil si pudieras hacer un mensaje POST a un worker y simplemente esperar el resultado, en lugar de devolver un valor, tu worker realmente te da una promesa. Y ahora puedes saber, ok, sé cuándo se va a completar. Y luego puedo actualizar mi interfaz de usuario en función de eso, ¿verdad? Bien, así que hay algunas bibliotecas que quiero mencionar, la primera es Commlink.

6. Usando UseWebWorkerHook para mejorar el rendimiento

Short description:

Existe una increíble biblioteca llamada UseWebWorkerHook que simplifica el proceso de creación de un web worker en React. Al definir el worker y usar la función sort worker, puedes descargar tareas que consumen mucho tiempo a un hilo separado, mejorando el rendimiento de la aplicación y la experiencia del usuario. El hilo principal se desbloquea y el spinner ya no se congela. Los web workers son útiles para tareas intensivas de CPU.

Eso es increíble. Hay otra increíble biblioteca creada por los propios Google Chrome Labs. Pero como otra biblioteca que personalmente me gusta mucho cuando estás creando cosas con React, es UseWebWorkerHook, que son solo dos pasos simples que puedes usar para crear lo mismo, ¿verdad? Simplemente creas un worker usando UseWebWorkerHook. Le pasas la función, como esa gran función que va a llevar mucho tiempo, en este caso la agregué como bubble sort, ¿verdad? Y te da la instancia del worker. Te da una instancia de una función para detener el worker y todas las cosas. Y cuando quieres ejecutarlo, simplemente haces sort worker, que es la función que obtuviste. Así que haces sort worker y simplemente pasas los datos relevantes. Y eso es todo. Simplemente defines el worker y lo usas. Y eso es todo lo que necesitas saber.

De acuerdo. Suficiente conocimiento, volvamos a la misma demostración de siempre de la que estabas hablando. Aquí, ahora voy a usar este nuevo botón que dice nueva ola. Y aquí, lo que estoy haciendo es exactamente lo mismo, que es crear un worker y permitir que ese worker haga el mismo bubble sort en su propio contexto. Ahora veamos qué le sucede al spinner cuando intento hacer eso. Hago clic en esto. Ahora mi spinner no está trabado ni congelado. Mi aplicación vuelve a ser utilizable y mis usuarios están felices. Mientras tanto, también pude realizar esta tarea muy grande en sí misma. Y si también quieres verificar esto mediante el rendimiento, intentemos hacer esto nuevamente y ver el seguimiento de rendimiento, ¿verdad? Si abro esta pestaña de rendimiento, hago clic en la carpeta donde estamos haciendo cosas, que es cuando mi aplicación se bloquea debido a la realización de tareas de forma sincrónica. Y si la cierro, verás que el hilo principal está gastando tiempo, como si lo abro aquí. Verás que hay una barra muy grande de 5.69 segundos que estaba bloqueando el hilo principal, similar a lo que hablamos, ¿verdad? Por eso el spinner se congela. Pero en el otro caso, si hago lo mismo nuevamente, iniciando el perfilado y haciendo clic en la forma de hacer las cosas del web worker, deberíamos ver que nuestro hilo principal está desbloqueado, ¿verdad? Si cierro esto de nuevo y vemos el perfilado ahora. Veríamos que ahora esa barra muy grande ya no está en el hilo principal, ¿verdad? Y si lo cierro, verás que ahora el hilo del worker tiene esa barra muy grande. Por eso el spinner no estaba trabado, ¿verdad? Porque el hilo del worker se encarga de esa tarea más grande. De acuerdo. Con esto, creo que hemos logrado algo en este aspecto y mejoramos la experiencia del usuario en estos escenarios. ¿Verdad? Así que sí, felicitaciones, buen trabajo en eso. Solo mencionaré algunas cosas más. Hay algunas instancias en las que puedes usar web workers, que es exactamente donde necesitas realizar tareas intensivas de CPU.

7. Web Workers and Considerations

Short description:

Puedes asignar un worker para realizar todos los cálculos, como verificar si Node ha sido actualizado o no, y cuál es el árbol actualizado. Cualquier tarea que tome demasiado tiempo y bloquee el bucle de eventos debería utilizar la estrategia de web workers. Sin embargo, debemos tener cuidado al elegir entre web workers y otras opciones. Tareas como llamadas de red y manipulación del DOM pueden no requerir web workers. Los web workers no tienen acceso al objeto document ni al almacenamiento local. Agregar más web workers puede aumentar la complejidad y los esfuerzos de mantenimiento. Por último, Postman está contratando y lanzando la función WeTen. Visita el sitio web de carreras y consulta el blog para obtener más información.

Y no quieres bloquear tu interfaz de usuario en eso, como mencioné, ¿verdad? Por ejemplo, la diferencia virtual del DOM que hace React, ¿verdad? Puedes asignar un worker para realizar todos los cálculos, como verificar si Node ha sido actualizado o no, y cuál es el árbol actualizado. Por lo tanto, todos esos cálculos se pueden asignar al web worker. Lo mismo puede aplicarse a la manipulación y procesamiento de imágenes y al dibujo en el lienzo. La idea principal es la misma. Cualquier tarea que tome demasiado tiempo y bloquee el bucle de eventos debería utilizar la estrategia de web workers.

Y nuevamente, una palabra de precaución, debemos ser sabios al elegir entre estas dos cosas, ¿verdad? Si ves tareas que están limitadas por E/S, como llamadas de red y otras cosas, no necesitas usar web workers en esos casos, ¿verdad? Porque esas tareas ya son asíncronas y solo agrega complejidad. De manera similar, si vas a manipular el DOM y quieres hacerlo en un web worker, un web worker no tiene acceso al objeto document, ¿verdad? Nuevamente, la razón es que tienen diferentes CPU y diferentes contextos, como diferentes núcleos de CPU, por lo que no saben qué está haciendo la ventana o el otro mundo. No tienen conocimiento de eso. Lo mismo ocurre con el almacenamiento local, porque nuevamente no tienen acceso a esa API. Y por último, pero no menos importante, no es como algo súper, necesitarías tener mucho cuidado si quieres usar web workers, ¿verdad? Porque cuando creces y sigues agregando web workers, solo aumenta la complejidad y puede ser muy difícil mantenerlos, ¿verdad? Por lo tanto, debes tener mucho cuidado si quieres seguir este enfoque o no. Esa debería ser la decisión a tomar.

De acuerdo, con esto, me gustaría terminar mi charla y espero que hayan obtenido algunas ideas de ella. Por último, pero no menos importante, estamos haciendo cosas increíbles en Postman en sí. Estamos contratando y si quieres ser parte de nuestro increíble viaje, visita nuestro sitio web de carreras y creo que estaremos encantados de tenerte a bordo. Y como mencioné antes, hemos estado trabajando muy duro para lanzar la función WeTen de Postman. Muchas personas me han preguntado cuáles serán las características. Y sé que la gente está muy emocionada por este lanzamiento de WeTen. Si quieres saber más al respecto, consulta el blog de Postman y echa un vistazo a las increíbles características que vienen. De acuerdo. Con esto, finalmente termino mi charla. Me gustaría agradecer a todos, a los organizadores, a la comunidad por organizar este increíble evento y por invitarme. Ha sido increíble estar aquí. Y por último, pero no menos importante, a la increíble audiencia. Felicitaciones a todos por hacer de este evento un éxito. Gracias nuevamente por invitarme y disfruten de la conferencia.

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 Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
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 Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
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.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
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 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn