Entendiendo los Patrones de Renderización

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.

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!