Entendiendo los Patrones de Renderización

Rate this content
Bookmark

React ha explotado en popularidad gracias al rendimiento y la experiencia de desarrollo inigualable que el DOM virtual y la reconciliación podrían ofrecer. Pero a medida que nuestras aplicaciones crecían, comenzamos a empujar los límites de la gestión del estado del cliente de una manera eficiente. Veamos cómo lograr una reactividad de grano fino y qué aporta la reanudabilidad a la mesa.

9 min
12 Dec, 2023

AI Generated Video Summary

Esta charla discute los patrones de renderización en la web, incluyendo el uso de React y el concepto de memoización. Explora la idea de usar señales para cambiar datos sin un re-renderizado completo y cómo marcos de trabajo como SolidJS, Vue, Svelte y Angular están adoptando señales. El equipo de React está desarrollando React para Get, un compilador que proporciona auto-memoización para reducir re-renderizados innecesarios. Diferentes marcos de trabajo tienen sus propias formas de usar señales, como ref superficial o ref en Vue, usar señal en Quick, y definir y acceder a señales en Angular y Svelte.

1. Introducción a los patrones de renderizado en la web

Short description:

Hola, vecindario de React. Hoy, discutiré los patrones de renderizado en la web, incluyendo el uso de React y el concepto de memoización. React introdujo la idea de abstraer el DOM y usar un DOM virtual para agrupar cambios y mejorar el rendimiento. Sin embargo, al usar un proveedor de contexto, todos los componentes hijos se vuelven a renderizar, lo que puede llevar a posibles problemas de rendimiento. Para abordar esto, el equipo de React está desarrollando React for Get, un compilador que proporciona auto-memoización. Esto permite que los componentes se memoricen en función de las props que utilizan, reduciendo los re-renderizados innecesarios y mejorando el rendimiento. Sin embargo, la memoización no es reactividad de grano fino, lo que lleva a la exploración de ideas alternativas para desafiar el DOM virtual.

Hola, React vecindario. Estamos aquí para hablar sobre los patrones de renderizado en la web. Entonces, primero que nada, ¿quién soy yo? Mi nombre es Atila Fasina, y soy un ingeniero DevRel en Crab Nebula. También soy un Experto Desarrollador de Google y puedes encontrarme en cada una de esas redes allí. Tengo un práctico ... Conseguí un práctico ... algunos atajos prácticos para ti, porque nombrar cosas en la web es difícil, y también puedes encontrarme aquí en esta plataforma en atila.io.

Entonces, hablemos de renderizar cosas en la web. Primero estaba React con un montón de ideas muy geniales, como usar la UI como una función del estado, y con eso llegó la UI declarativa, renderizando props, flujo unidireccional, y Pero garantizar la consistencia puede hacer que el DOM sea lento, porque eliminar y volver a agregar elementos al DOM es una acción muy costosa. Entonces React y otros frameworks tuvieron la idea de abstraer el DOM, y luego podemos agrupar todos los cambios, y luego reconciliar los cambios y agregar todo junto de una vez. Entonces, con eso, tenemos este modelo de renderizado, donde puedes juntar todos los cambios en un lote, y abstraemos el DOM en un DOM virtual, y eso nos da este árbol de componentes basado en los datos que tienen. Entonces, esencialmente en este caso, tienes el componente padre con las props A y B, pero entonces si la prop A cambia, todo lo que depende de A también va a cambiar. Pero no nos detenemos allí, porque no hay forma de rastrear en el DOM virtual qué son las cosas que cambian. Entonces, todo lo que realmente es un hijo de donde vive la prop A y se define se vuelve a renderizar también. Y si eres un desarrollador de React, que creo que la mayoría de ustedes lo son, has visto eso un montón de veces, has hablado de eso un montón de veces, y nada de eso es nuevo. En mi experiencia, lo que se vuelve nuevo es cuando tenemos un proveedor de contexto en este caso. Y entonces estamos inclinados a pensar que si cambiamos una prop en un proveedor de contexto, solo los componentes que usan esa prop van a volver a renderizarse. Pero esencialmente lo que sucede es que todo lo que es un hijo de ese proveedor de componentes cambia. Y por eso, en mi experiencia, he visto a un montón de personas pisando una mina terrestre porque terminas volviendo a renderizar toda tu aplicación con un solo cambio de prop. Entonces, con eso en mente, el equipo de React está trabajando en este compilador, que es React for Get, que además de garantizar un montón de buenas mejores prácticas, también va a proporcionar auto-memorización. ¿Qué es eso? Lo que eso significa es que los componentes van a ser memorizados en función de las props que usan. Entonces, si un componente usa la prop A, se va a memorizar para solo renderizar si la prop A cambia. Y luego si no está usando ninguna prop, solo estados locales, no se va a renderizar en base a otros cambios, y para las props B y así sucesivamente. Entonces eso puede encapsular los re-renderizados y contenerlos. Esa es una idea muy buena y al hacer eso, puede permitir que algunos renderizados no ocurran realmente, y por lo tanto, el modelo mental se vuelve un poco más fácil de razonar cuando estás hablando, especialmente a las personas que vienen a React. Pero esencialmente la idea de la memoización es para grandes cálculos. Entonces, la parte de auto-memoización es más, en mi opinión, una cosa de DX que un cambio real a una optimización de rendimiento. A eso también debemos decir que la memoización en realidad no es reactividad de grano fino. Y con eso, abrimos el camino para ir un poco más granular. Entonces, surgieron algunas ideas para desafiar el VDOM.

2. Señales y su uso en marcos de trabajo

Short description:

En lugar de volver a renderizar todo el componente, las señales te permiten cambiar los datos sin necesidad de una re-renderización completa. Marcos de trabajo como SolidJS, Vue, Svelte y Angular están evaluando o adoptando señales. La reactividad de grano fino requiere más control y conciencia de las actualizaciones de datos. Entender la herramienta elegida es esencial. Diferentes marcos de trabajo tienen sus propias formas de usar señales, como shallow ref o ref en Vue, use signal en Quick, y definir y acceder a señales en Angular y Svelte. Los desarrolladores están explorando mejores formas de describir la interfaz de usuario con señales. Ven a charlar conmigo en X o encuéntrame en YouTube.

Por ejemplo, en lugar de renderizar y agrupar los cambios y volver a renderizar, surgió una nueva idea de que si renderizas cosas, puedes tocar solo lo que cambiaste. Entonces eso esencialmente se traduce en desacoplar la lógica de renderización de los data. Y eso es exactamente de lo que tratan las señales. Puedes cambiar los data sin necesidad de volver a renderizar todo tu componente. Utiliza el patrón de observador, que esencialmente, los data son capaces de notificarte cuando ocurren cambios. Tu sistema de renderización puede rastrear si los cambios ocurren. Y luego, cuando estás renderizando, la parte que es responsable de tu interfaz de usuario puede obtener el nuevo valor en este caso. Entonces, mirando nuestro panorama de frameworks, lo que sucedió es que SolidJS llegó y dijo, Oh, me gustan las señales, vamos a traerlas de vuelta. Y todos los demás frameworks estaban más orientados hacia VDOM, algunos de ellos como Svelte y Vue, más específicamente, estaban haciendo algunas otras cosas que estaban más en línea con lo que son las señales. Y adelantándonos un par de años, todos los frameworks están evaluando o adoptando señales mientras hablamos, por lo que este gráfico es muy representativo de como Vue 3 y Svelte 5, pero QUIC y Angular ya tienen señales en algún lugar de su base de código. Pero sería deshonesto si no hablara de los compromisos, uno de ellos es que la reactividad de grano fino es un poco menos resistente que el VDOM porque requiere que tengas más control y requiere un poco de cuidado para no desechar todo y luego hacerlo. Entonces, si vas a ir a grano fino, necesitas estar más consciente de cómo se actualizan tus data y asegurarte de que tu componente puede responder. También frameworks como SolidJS tiene un montón de ayudantes que pueden ayudarte a asegurar esta reactivity para proporcionar una gran developer experience. Pero de todos modos la conclusión de mi charla es que en realidad no hay almuerzo gratis. Puedes elegir VDOM, puedes elegir señales, pero al final del día necesitas entender la herramienta que estás utilizando. Y solo para que puedas terminar, veamos cómo se utilizan las señales en diferentes frameworks. Como por ejemplo Vue, tienes el shallow ref o ref donde puedes definirlos. En Quick tienes el use signal y luego puedes configurar, puedes cambiar el valor así y puedes acceder al valor con el valor de countout y esencialmente el compilador los va a convertir en getters y setters como las señales necesitan. Para Angular defines una señal así y puedes establecerla o actualizar la señal basándote en el valor anterior y puedes acceder a la señal mediante un getter de función. Para Svelte defines una señal y puedes crear un getter y puedes crear un setter para esa señal también. Entonces, para resumir nuestra breve charla, lo que sucedió es que teníamos un modelo que era bastante bueno para lo que teníamos antes con React y el dom virtual y todos los demás frameworks usándolos. Ahora mismo muchos desarrolladores están pensando que hay mejores formas de describir la interfaz de usuario con señales y cosas así y por lo tanto más frameworks están yendo en esa dirección y te recomiendo que le eches un vistazo a eso. Y eso fue todo lo que tenía para ti. Así que muchas gracias. Por favor, ven y charlemos en X o mírame en YouTube. ¡Adiós!

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 2022React Summit 2022
20 min
Routing in React 18 and Beyond
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.
React Advanced Conference 2021React Advanced Conference 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Why are we devs so obsessed with decoupling things that are coupled nature? tRPC is a library that replaces the need for GraphQL or REST for internal APIs. When using it, you simply write backend functions whose input and output shapes are instantly inferred in your frontend without any code generation; making writing API schemas a thing of the past. It's lightweight, not tied to React, HTTP-cacheable, and can be incrementally adopted. In this talk, I'll give a glimpse of the DX you can get from tRPC and how (and why) to get started.
React Summit 2023React Summit 2023
22 min
Thinking in React Query
In this talk, I'll explain React Query from a different perspective. After having maintained React Query for over two years and having answered many questions (often the same ones multiple times), I feel like there might be a fundamental understanding missing about the lib. I'll start with a quick introduction about my journey into open source and how I got to know React Query, followed by showing which mindset change is beneficial when working with React Query - how to "think in React Query". I'll have 3 major takeaways: 1) React Query is not a data fetching library It's an async state manager, we'll quickly talk about what makes a state manager, why React Query is one and what "async state" means. 2) staleTime is your best friend I've seen a bit of confusion about how to use React Query as a state manager, so I'll explain why setting staleTime is mostly all you need 3) parameters are dependencies This is important to understand to show the boundaries between client state and server state, and is essential when doing state management with React Query I will then end with a note on "separation of concerns" and about the tradeoffs of just calling `useQuery` wherever you need it in your component tree.
React Advanced Conference 2021React Advanced Conference 2021
20 min
Advanced Patterns for API Management in Large-Scale React Applications
In this talk, you will discover how to manage async operations and request cancellation implementing a maintainable and scalable API layer and enhancing it with de-coupled cancellation logic. You will also learn how to handle different API states in a clean and flexible manner.
React Summit 2023React Summit 2023
19 min
7 TypeScript Patterns You Should Be Using
In this talk, we will be going over a number of common useful and best-practice-proven TypeScript patterns to use in React 18. This includes how to correctly type component properties, children and return types, using React's built-in types, typing contexts, and the usual enum rant (but constructively).

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
Workshop
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
Prerequisites: To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.