El Arte de Ignorar las Mejores Prácticas para el Rendimiento de React

¿Alguna vez has querido ser un chico malo de React? Sé que todos ustedes han sido buenos ingenieros siguiendo todas las mejores prácticas, pero ¿dónde te ha llevado eso? ¿A proyectos complejos de React con componentes lentos? Luego te encuentras queriendo destrozar tu teclado mecánico, preguntándote por qué necesitas usar un flujo de datos unidireccional para evitar llamar a los hooks de React condicionalmente, para almacenar el estado usando el hook useState de React. Escuchas una pequeña voz susurrando, puedes ser un alborotador de React. Puedes romper todas estas reglas. Piensas que cruzar la calle sin respetar el semáforo, tirar basura y andar en motocicleta es malo. Espera hasta que llames condicionalmente a los hooks de React, construyas componentes impuros e incluso incluyas una segunda biblioteca de UI.

Me llamo tigerhooks. Puedes encontrarme en notwoods y en todas las redes sociales. Soy un ingeniero de software senior que trabaja en Microsoft y anteriormente ayudé a construir tres navegadores web, Edge, Chrome y Firefox. He trabajado con React durante más de ocho años y te mostraré el arte de ignorar las mejores prácticas. Cualquier documentación que leas viene con un asterisco oculto. Cubre la mayoría de los casos, pero todos tenemos diferentes configuraciones y entornos. Esta charla te mostrará los casos extremos para que sepas cuándo seguir y cuándo no seguir las mejores prácticas y cómo ponerte en la lista de Santa este Navidad. Dado que estamos en un territorio peligroso, usa lo que estoy a punto de mostrarte con precaución. Algunos de estos trucos pueden hacer que tu código sea difícil de seguir. Usa tu mejor criterio, evalúa los compromisos y comunica lo que estás tratando de hacer. Esto es lo que te mostraré hoy. Hablaremos sobre cuándo decide React volver a renderizar, luego cómo aislar hooks y cambios de estado costosos usando componentes impuros, y cómo actualizar solo los componentes hoja usando una biblioteca de UI diferente.

Comencemos con el primer tema. ¿Cuándo decide React volver a renderizar? Bueno, React parte de una regla simple. Cada renderización comienza con un cambio de estado. Puede que estés pensando, espera, ¿los componentes no se vuelven a renderizar cuando cambian sus props? ¿Cuando cambia el contexto? Pero no, el truco es que cada vez que un componente se vuelve a renderizar, también se vuelven a renderizar todos los componentes descendientes. React utiliza las renderizaciones para determinar qué necesita cambiar para mantener tu UI sincronizada con el estado. Tu componente devolverá una mezcla de otros componentes y elementos HTML. Cuando se encuentra con otro componente, React procederá a renderizarlo y ese componente devolverá otra mezcla de componentes y elementos HTML. Eventualmente, React solo se quedará con un árbol HTML. Ahora que ha terminado de volver a renderizar los componentes, comenzará el proceso de comparación del DOM virtual. React comparará el nuevo HTML con el HTML renderizado previamente y luego actualizará los nodos que han cambiado en el DOM. Pero React no piensa demasiado en qué componentes renderizar. Podrías pensar que solo los componentes que leen el estado se actualizarán, pero en realidad todo se vuelve a renderizar. No importa si el estado se pasa como prop, o si el componente no recibe ninguna prop en absoluto. Cada vez que se hace clic en este botón de incremento y se actualiza el estado del contador, el componente MyCounter y todos sus descendientes se volverán a renderizar, como se indica con estos destellos verdes.

Aunque el componente de título no lee el estado del contador, también se vuelve a renderizar. La única excepción a esto es React.memo. Memo coloca una capa adicional alrededor de un componente, lo cual le dice a React: si mis props son las mismas, prometo solemnemente que devolveré exactamente el mismo resultado. Puedes recordar lo que devolví la última vez. No es necesario volver a renderizarme. Ahora, cada vez que se hace clic en este botón de incremento y se actualiza el estado del contador, MyCounter se volverá a renderizar y luego intentará volver a renderizar a sus descendientes. El componente de título no lee el estado del contador, por lo que sus props no han cambiado. Como resultado, no se vuelve a renderizar, gracias a React.memo. La visualización de MyCounter todavía se vuelve a renderizar, ya que esta prop de contador está cambiando. Ahora, Memo es un poco extraño con React.Context. El contexto actúa como un segundo conjunto de props invisibles, que se transmiten a través de cada componente. Entonces, si tu componente está utilizando React.memo, las props y el contexto que está leyendo deben ser exactamente los mismos, de lo contrario, el componente se volverá a renderizar. Si quieres ver cuándo se vuelve a renderizar un componente en tu propio código, React DevTools puede ayudar. Después de abrir las herramientas de desarrollo de tu navegador, puedes ir a la pestaña Profiler de React, hacer clic en el icono de engranaje para abrir la configuración de la extensión y luego activar una opción etiquetada como Resaltar Actualizaciones Cuando los Componentes se Vuelven a Renderizar. Esto hará que se muestren rectángulos verdes alrededor de cada componente que se haya vuelto a renderizar en tu interfaz de usuario. Y si estás tratando de rastrear qué está causando un rerender en tu código, puedes activar una opción diferente etiquetada como Registrar por qué cada componente se renderizó durante el perfilado. Puedes encontrarla en la pestaña Profiler de las configuraciones de React DevTools. Luego, cuando guardes una grabación utilizando el Profiler de React, se capturará cada renderización y podrás ver qué la desencadenó. Si quieres obtener más información, puedes consultar el excelente artículo de Josh Komu con ejemplos en vivo con los que puedes jugar.

Ahora, React recomienda que en lugar de preocuparte por la frecuencia con la que se vuelve a renderizar, simplemente escribas tus componentes para que se rendericen rápidamente. Ya sabes, asegúrate de que tú y todo tu equipo siempre escriban código perfectamente optimizado. ¿Qué podría salir mal? Pero cuando, inevitablemente, terminas con componentes costosos, podemos engañar a React para que se vuelva a renderizar con menos frecuencia. Ahí es cuando empezamos a romper las reglas e ignorar las mejores prácticas.

Ahora que sabemos que cada re-renderizado en React se desencadena por un cambio de estado, veamos cómo evitar estos cambios de estado. Para nuestro segundo tema, discutiremos un enfoque para evitar cambios de estado mediante el aislamiento de hooks costosos. ¿Qué sucede si tenemos hooks que obtienen algunos datos y luego los colocan en el estado? Después de que se ejecuta el efecto, React se actualizará. Comencemos con un ejemplo de hook llamado useGetData. Obtiene algún valor de estado y luego llama a setState, lo que provoca un re-renderizado. Pero, ¿qué sucede si ese primer estado se utiliza para obtener más datos? Por ejemplo, podríamos usar un ID del fetch anterior para luego iniciar otro efecto de fetch. Después de que se ejecuta cada efecto, React se volverá a renderizar nuevamente. Eso puede ser muchos re-renderizados, incluso si ni siquiera estamos utilizando estos valores de estado intermedios. Si solo usamos el último estado en nuestra interfaz de usuario, todos esos otros re-renderizados fueron un trabajo desperdiciado. Dado que cada actualización de estado le cuesta al componente y a todos sus descendientes renderizarse, eso puede resultar en muchos componentes que se renderizan innecesariamente.

¿Cómo podemos aislar esto? Bueno, idealmente, una cadena como esta debería refactorizarse. En lugar de usar el estado para activar efectos, puedes configurar una cadena de promesas dentro de un solo efecto. Pero eso también requiere tiempo invertido en limpiar el código y quitado del trabajo futuro. En su lugar, podemos aislar los cambios de estado en un nodo hoja único para que el resto del árbol no necesite actualizarse hasta que el valor final esté listo. Escribiremos un componente especializado de React que solo ejecuta efectos secundarios y no devuelve ningún hijo, por lo que será más barato de renderizar. Aquí, hemos creado un componente llamado ExpensiveEffect que simplemente se encarga de llamar al hook useGetData. Siempre devolverá null. El resultado final del hook se pasará de vuelta al padre utilizando props.setState, que actualizará el estado del padre. Ahora, todos los cambios de estado en el hook costoso están aislados por este componente de efecto. Esto rompe el flujo de datos unidireccional. En su lugar, hay un pequeño bucle donde pasamos la entrada y luego obtenemos la salida del componente de efecto. Ahora, los datos se obtienen en ExpensiveEffect y luego se pasan a la aplicación, que se pasa de vuelta a la interfaz de usuario. Es un refactor rápido que puede mejorar mucho el rendimiento al separar el estado de los componentes secundarios en el árbol. En Microsoft Loop, teníamos un componente en la parte superior de nuestro árbol que se renderizaba cinco veces debido al estado intermedio utilizado en un hook. Envolver ese único hook en un componente de efecto hizo que esta ruta de inicio fuera cinco veces más rápida. Cualquier componente costoso que tenga mucho estado innecesario puede beneficiarse enormemente del uso de componentes de efecto.

Este patrón también introduce un superpoder adicional. Podemos utilizar toda la flexibilidad que tenemos al decidir cuándo renderizar componentes, a diferencia de los hooks. ¿Quieres llamar condicionalmente a tu hook? Bueno, simplemente puedes renderizar condicionalmente los componentes de efecto. ¿Necesitas cargar perezosamente tu hook? Envuelve el componente de efecto con React.lazy y suspense. Este sufijo de efecto es una convención utilizada para indicar que este componente no renderiza nada y solo obtendrá datos.

Este patrón se adopta de Jetpack Compose de Android, que es una biblioteca que tiene una funcionalidad muy similar a React. En Jetpack Compose, no hay diferencia entre los hooks y los componentes. Todos son componibles. Los componibles que devuelven datos están en camel case, como load data y mutable state of. Los componibles que muestran la interfaz de usuario están en Pascal case, como React, como app. Y los componibles que solo ejecutan algún efecto secundario están en Pascal case pero con un sufijo de efecto.

Al envolver tus cambios de estado en un componente hijo, podemos evitar que afecten al resto del árbol de React. El componente de efecto no tiene hijos propios para volver a renderizar y no puede hacer que los componentes hermanos se rendericen. Hemos logrado aislar todos nuestros cambios de estado.

Ahora, para nuestro tercer tema, discutiremos cómo reducir la cantidad de componentes en un árbol que se renderizan. Si nuestro estado está muy arriba, toda la aplicación se volverá a renderizar. Los componentes de efecto nos permiten reducir la frecuencia con la que esto sucede, pero aún así debe suceder en algún momento.

¿Y qué pasa si tienes una lista grande o una parte de los datos solo se utiliza, por ejemplo, en algunos elementos de la lista? ¿Realmente necesitamos volver a renderizar toda la lista solo para actualizar algunas cadenas? Podríamos usar el contexto para pasar un valor desde el abuelo hasta su nieto, pero aún así se necesitarán rerenderizaciones porque estamos usando useState de React.

Pero, ¿qué pasa si usamos state sin useState? Necesitaríamos hacer lo que React hace por nosotros, almacenar una parte del estado, tener una forma de establecer ese estado e informar a todos los interesados que el estado ha cambiado. Bueno, React hace esto bastante bien, pero otras bibliotecas también pueden hacerlo. Así que sigamos adelante y comencemos a usar una segunda biblioteca de UI completamente competidora, Svelte.

El truco es que en realidad no estamos usando Svelte para su código de UI. En su lugar, desempaquetaremos el paquete y solo usaremos una API especial de tienda. Las tiendas de Svelte actúan como un useState portátil. Tienen un método set para actualizar el estado y los componentes que observan la tienda. Incluso puedes pasar una función de retorno de llamada para actualizar el estado en función del valor de estado anterior, al igual que en React. La API de la tienda es independiente del resto de Svelte, por lo que no necesitamos preocuparnos por importar nada más. Puedes usar eslint para deshabilitar las importaciones directas de Svelte en tu código y solo permite importar desde Svelte/store.

Ahora, en lugar de pasar un valor de estado sin procesar, podemos pasar una tienda de Svelte en su lugar. Puedes hacerlo usando props o contexto, como valores regulares. La tienda no cambia de identidad, por lo que cambiar los valores no afectará a React.memo. Sin embargo, en algún momento, todavía necesitamos convertir la tienda de Svelte de vuelta a estado de React. En lugar de colocar el hook dentro del componente de la rama ancestral, podemos colocar múltiples hooks dentro de cada componente hoja. Usaremos el hook externo usync incorporado de React. Toma dos funciones de retorno de llamada, una utilizada para suscribirse a la tienda y observar los cambios, y otra para obtener el valor actual de la tienda. Cada vez que la tienda cambia, React lo usará como una señal para actualizar el estado interno del hook utilizando el valor actual de la tienda, lo que hace que el componente se vuelva a renderizar.

Ahora los componentes intermedios no necesitan volver a renderizarse en absoluto. Solo los componentes hoja son notificados cuando la tienda cambia, por lo que ningún otro componente se vuelve a renderizar. Al pasar simplemente un objeto de tienda estática, hemos roto las limitaciones del useState de React manteniendo una API similar. Combinado con los componentes de efecto, podemos preparar el estado y luego pasarlo sin volver a renderizar a los ancestros en absoluto. Al pasar store.set a nuestro componente de efecto en lugar de la función de retorno de llamada setState de React, nunca necesitamos trabajar con useState en nuestro componente superior y, por lo tanto, nunca necesitamos volver a renderizarlo. Las tiendas de DataModel también se pueden usar fuera de React o cualquier biblioteca de UI, por lo que puedes gestionar el estado reactivo en clases de modelo de datos, en un worker o incluso en el servidor. Esto es en realidad muy similar a una optimización de rendimiento que Redux hace bajo el capó. Redux simplemente pasa una referencia estática de la tienda utilizando el contexto de React.

El estado de React no se involucra hasta que hayas llamado al hook useSelector de Redux. Pero las swap stores están mucho más cerca de la API useState, por lo que necesitan menos código de inicialización, especialmente para estados simples. Por cierto, esto también significa que Redux tendrá un mejor rendimiento que el hook useReducer incorporado de React, especialmente si tienes un gran almacén de reducers.

Cambiar el valor con useReducer volverá a renderizar todo el árbol cuando algo cambie, porque se está traduciendo en estado de React en la parte superior del árbol. En cambio, useSelector de Redux solo actualizará los componentes hijos cuando cambie el estado seleccionado. Es posible que también hayas oído hablar de esta nueva y genial API llamada Signals en otras bibliotecas como React y Solid. SlotStore tiene una API algo similar a Signals, ¿eso significa que podrías usar Signals en su lugar? Sí. Pero sabes qué, me gustan las SlotStores. Tienen una característica adicional en comparación con la mayoría de las bibliotecas de Signals. Saben cuántos listeners están adjuntos y pueden iniciar y limpiar según si tienen o no listeners.

Esto es realmente genial para envolver otras APIs como un sistema observable genérico, como MatchMedia para escuchar consultas de medios CSS. Podemos envolver MatchMedia en una store que solo atacará un listener de evento una vez, cuando al menos un componente haya comenzado a suscribirse a la store. Los componentes posteriores no activarán esta devolución de llamada, por lo que no tenemos que preocuparnos por tener toneladas de listeners de eventos adjuntos al MatchMedia original. Una vez que todos los componentes se hayan desmontado y cancelado la suscripción, podemos limpiar nuestro listener de eventos y evitar fugas de memoria. Esta característica le da a SlotStore una ventaja sobre otras bibliotecas de Signals, incluso sobre las nuevas podas de Slot. Pero, una propuesta reciente de TC39 para estandarizar las Signals dentro del lenguaje JavaScript también incluye esta característica adicional. Por lo tanto, es posible que la veamos llegar a otras bibliotecas de Signals también.

Estos son todos trucos reales que uso para mejorar el rendimiento en productos de Microsoft, como Microsoft Loop, evitando grandes refactorizaciones y reescrituras. Los comparto contigo para que también puedas aprender el arte de ignorar las mejores prácticas, pero para mejorar el rendimiento de React. Gracias por escuchar. Puedes encontrar mi blog en línea en tigeroaks.com y echar un vistazo a la aplicación en la que trabajo en loop.microsoft.com.