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