Mitos y Leyendas de React

Hola a todos. Bienvenidos a la charla sobre mitos y leyendas en React. Permítanme comenzar con una pequeña introducción. Mi nombre es Nadia. He sido desarrolladora durante mucho tiempo. Trabajé para Atlassian durante unos cinco años en un producto que algunos de ustedes podrían conocer y amar llamado Jira. Hasta hace muy poco, vivía en Australia rodeada de loros y canguros. Pero hace unos meses, me cansé de todo este buen clima y playas perfectas y me mudé a Austria por la única razón de que soy perezosa y Austria es más fácil de deletrear.

Además, soy un poco nerd. Uno de mis pasatiempos nerd es investigar cómo funcionan las cosas en detalle y luego escribir artículos profundos sobre esos temas. Usualmente escribo para desarrolladores de front-end, más específicamente para desarrolladores de React. Uno de los principales enfoques de esas investigaciones, lo que más me interesa recientemente es el rendimiento de React. Y el tema del rendimiento en React es increíblemente interesante. React es una herramienta fantástica que nos permite escribir aplicaciones complicadas de manera muy fácil y rápida. Pero como resultado, también es muy fácil escribir código que hará que nuestras aplicaciones sean muy lentas y con retraso. Y la mayoría de las veces, es debido a las re-renderizaciones. Re-renderizamos demasiado rápido o demasiados o componentes demasiado pesados. Así que la clave para un buen rendimiento en React es saber y poder controlar cuándo los componentes se montan y re-renderizan. Y luego prevenir aquellos que son innecesarios.

Así que hoy, quiero compartir algunos mitos y conceptos erróneos que son bastante comunes entre los desarrolladores y que pueden afectar negativamente la situación de las re-renderizaciones en todas las aplicaciones. Pero antes de hacer eso, recordemos rápidamente qué es el montaje, las re-renderizaciones y qué son las re-renderizaciones innecesarias. Todo comienza con el montaje. Esta es la primera vez que el componente aparece en la pantalla. Es cuando React inicializa y conecta todo, por lo tanto, la renderización inicial dispara todos los callbacks y efectos de uso por primera vez. Después de eso, si tu aplicación es interactiva, será el momento de las re-renderizaciones. La re-renderización es cuando React actualiza un componente ya existente con algunos datos nuevos. Estas suelen ocurrir como resultado de la interacción del usuario con tu interfaz o de algunos datos externos que llegan. Las re-renderizaciones son una parte crucial del ciclo de vida de React. Sin ellas, no habría actualizaciones en la interfaz y, como resultado, no habría interactividad. Así que no es algo de lo que quisiéramos deshacernos.

Las re-renderizaciones innecesarias, sin embargo, son una historia completamente diferente. Imagina una aplicación de React, solo un árbol de componentes como cualquier otra aplicación, y en algún lugar en la parte inferior de este árbol, tenemos un componente de entrada donde un usuario puede escribir algo. Cuando esto sucede, quiero actualizar el estado de esta entrada y todo lo relacionado con los datos del usuario, como mostrar algunas sugerencias útiles mientras el usuario está escribiendo. Esto es re-renderización. Lo último que quiero, sin embargo, es que toda la aplicación se re-renderice en cada pulsación de tecla. Imagina lo lento que será escribir en este campo si algo así sucede. Definitivamente no es algo que alguien llamaría una aplicación de rendimiento. Este es un ejemplo de re-renderizaciones innecesarias, y esas son exactamente el tipo de re-renderizaciones de las que querríamos deshacernos.

Y cuando se trata de prevenir re-renderizaciones, existe este gran mito en el que de alguna manera todos creen. Yo lo llamo el Gran Mito de las Re-renderizaciones. Va así. Un componente se re-renderiza cuando sus props cambian. Es increíble, realmente. Todos lo creen. Nadie lo duda. Y simplemente no es cierto. Para entender eso, profundicemos un poco más en por qué ocurren las re-renderizaciones en primer lugar. Todo comienza con el cambio de estado. Cualquier desarrollador de React probablemente reconocerá el código. Tenemos un componente padre. Renderiza un componente hijo y tiene un hook useState. Cuando se activa setState, todo el componente padre se re-renderizará. El cambio de estado es la fuente inicial de todas las re-renderizaciones. Es el rey de las re-renderizaciones por así decirlo. Por eso está en la corona. Después del cambio de estado, es el momento para que React propague esta actualización a otros componentes. React hace esto de manera recursiva. Toma los hijos directos de un componente con estado, re-renderiza esos, luego re-renderiza los hijos, y así sucesivamente hasta que alcanza el final del árbol de componentes o se detiene explícitamente. Esta es la siguiente razón para que un componente sea re-renderizado cuando su componente padre se re-renderiza. Si miramos el código, una vez que ocurre el cambio de estado en el componente padre, todos los hijos que este componente tiene se re-renderizarán como resultado.

Se vería algo así. Se desencadena una actualización de estado. El componente padre se re-renderiza. Los hijos se re-renderizan, los hijos de los hijos se re-renderizan, y así sucesivamente.

Una cosa interesante aquí es que, como puedes ver, no he mencionado nada sobre props aquí, ni una sola vez. ¿Qué pasará si el componente hijo tiene algunas props? Realmente nada. Durante el ciclo de vida normal de React, React en realidad no compara props en absoluto. Si hay un hijo, se re-renderizará.

Esto me lleva a otro mito que se deriva del primero, el mito de que deberíamos memoizar todas las props no primitivas en un componente para evitar que se re-renderice. Nuevamente, esto es un mito, no es cierto. Como resultado de esta creencia, es bastante común ver código que se ve así. Un callback está envuelto en useCallbackHook, lo cual probablemente esté bien si es solo uno, pero luego habrá otro y otro hasta que la hermosa lógica del componente quede enterrada bajo este lío incomprensible e ilegible de useMemos y useCallbacks. Sin ninguna razón en absoluto. Todos esos son simplemente inútiles y no previenen nada. Todo esto porque olvidamos un paso importante aquí. Memoizar el propio componente. Para que la memoización de props funcione como esperamos, el componente también necesita ser memoizado. Necesita estar envuelto en un React.memo. Solo entonces React se detendrá antes de re-renderizar y verificará sus props. Así que este es finalmente el caso donde la prop onChange necesita estar envuelta en useCallback. Si ninguna de las props cambia y solo entonces React se detendrá y no re-renderizará más.

El siguiente mito, probablemente el más controvertido. Contexto. Desafortunadamente, el contexto tiene mala reputación cuando se trata de re-renderizaciones. Parte de ella, por supuesto, está merecida. Pero también debido a esta reputación, a veces la gente no se da cuenta de que el contexto puede ser una herramienta muy útil en la lucha contra las re-renderizaciones. Veamos por qué. Imagina de nuevo un gran árbol de componentes con un componente en algún lugar en la parte superior queriendo pasar algunos datos al componente en la parte inferior, el rosa. Y simplemente pasamos estos datos a través de props como de costumbre. ¿Qué pasará desde la perspectiva de las re-renderizaciones? Nada bueno. El estado cambia en la parte superior, todos los hijos se re-renderizan, sus hijos de hijos también se re-renderizan hasta que estos datos llegan al componente que realmente los necesita.

Sin embargo, el contexto nos permite hacer un poco de trampa y evitar ese árbol de componentes. Si simplemente extraemos estos datos que queremos pasar al contexto y los usamos directamente en el componente rosa, entonces solo el componente con los datos en sí y el componente que realmente los usa se re-renderizarán. El resto de la aplicación simplemente se quedará ahí tranquilamente y no hará absolutamente nada.

Bien, los gatitos son divertidos, pero echemos un vistazo más de cerca a la vida normal y a los componentes normales. Supongamos que quiero implementar una página que se vea así. Diseño de página de dos columnas, navegación a la izquierda, área de contenido principal a la derecha. En la navegación quiero tener un botón que expanda y colapse la navegación. Y quiero renderizar un número diferente de bloques en la parte inferior del área de contenido dependiendo de si la navegación está expandida o colapsada. Si empiezo a implementarlo con props normales, se vería algo así. Tendríamos una página que mantiene el estado de navegación, pasa ese estado al botón que lo expande a través del componente de navegación y escucha el callback en él. Y luego tendríamos que pasar estos datos al componente de página a través de todas las capas hacia abajo, hacia abajo, hacia abajo hasta el nivel donde están esos bloques que necesito renderizar. Y nuevamente, desde la perspectiva de las re-renderizaciones no es genial. Cada expansión o colapso de la navegación resultará en re-renderizaciones de absolutamente todo.

Lo que puedo hacer en su lugar aquí es extraer esta lógica de expansión y colapso en el contexto, solo la lógica, nada más. Esto se vería algo así, el mismo estado que controla la navegación, tendríamos un valor al que pasaríamos el estado en sí y la función de alternar, y luego pasaríamos este valor al proveedor de contexto. De repente nuestra página, en lugar de toneladas de código y props por todas partes, simplemente se convierte en algo tan limpio como esto. Contexto en la parte superior, navegación, y contenido pasados a él como hijos. Y luego en algún lugar de la navegación, tendríamos el botón que simplemente usa la función de alternar directamente del contexto. Y en algún lugar del área de contenido, tendríamos el bloque con elementos que usan el estado de navegación directamente del contexto.

Pero aunque este ejemplo se ve genial en teoría, en la vida real es, por supuesto, un poco más complicado, como siempre. En la vida real, todavía tenemos un problema con el contexto que tiene mala reputación por las re-renderizaciones. Principalmente esta reputación proviene de dos hechos. El primero es que las re-renderizaciones relacionadas con el contexto se desencadenarán en cada hijo que use este hook de contexto, independientemente de si usa los datos reales o no. Así que en nuestro caso, el componente a la izquierda que solo usa la función de alternar, en teoría, no debería preocuparse por el estado en absoluto, pero en la práctica, ambos componentes se re-renderizarán cuando el contexto cambie. Y el segundo problema aquí es que esas re-renderizaciones son imparables. No hay una forma sensata de prevenirlas. Usar memo o hooks de callback no ayudará. Sin embargo, hay otro truco que puede ayudar aquí si este comportamiento realmente causa problemas de rendimiento. Podemos simplemente dividir esos proveedores de contexto en dos. En lugar de un solo valor que contenga tanto la función de alternar como el estado, podemos tener dos valores separados.

Y ahora, cuando los separamos, cuando el estado expandido ha cambiado, el volumen de la API, el objeto que contiene la función toggle, no cambiará. Así que el componente que solo usa toggle no se re-renderizará. En el código, se vería algo así.

En lugar de este proveedor grande y monolítico, tendríamos dos, bajo el mismo techo del componente proveedor colapsado. Todavía tendríamos el mismo estado y los mismos hijos, pero tendríamos un contexto separado. Tendríamos un contexto separado solo para los datos de estado, y un contexto separado para la API con un montón de funciones solamente.

Ahora, como puedes ver, el contexto que contiene la API no depende del estado, por lo que su valor no cambiará con la actualización del estado, y como resultado, los componentes que usan esta API no se re-renderizarán.

Y ahora la gran pregunta aquí. ¿Deberíamos realmente usar contexto en nuestras aplicaciones? Y la respuesta es tal vez no. En la vida real, más probablemente, usarías alguna herramienta de gestión de estado como Redux en lugar de contexto. Pero el modelo mental y el comportamiento de las re-renderizaciones serán exactamente los mismos con esas herramientas, solo que son más convenientes de usar. Así que en lugar de contexto, si entiendes el contexto, cualquier gestión de estado después de esto será pan comido.

Y para el mito final de los re-renderizados de hoy, el atributo key. Este es mi favorito, probablemente es la característica más utilizada y la menos entendida en React. Lo usamos a diario cuando estamos renderizando arrays de elementos, y YesLint luego nos grita que la key es obligatoria y necesitamos poner algo allí. Pero, ¿qué sabemos realmente sobre esta key, qué exactamente debería ir allí, para qué sirve? Si preguntas a tus colegas ahora mismo esas preguntas, ¿cuál será la respuesta? Probablemente será algo como esto. Dirían que la key debe ser única y que el índice del array no debería usarse como key. ¿Pero por qué? ¿Qué tan única debería ser? ¿Puedo simplemente hacer algo como esto en su lugar? Y si no, ¿por qué no?

Pero si presionas con esas preguntas un poco más, a veces la gente dirá que necesitamos la key para prevenir re-renderizados. Y este es el divertido. Aunque, sí, la key de hecho debería ser única. Pero no tiene nada que ver con prevenir re-renderizados, usualmente. Esto es solo un mito. Como ya sabemos, si un componente se re-renderiza, todos sus elementos secundarios se re-renderizarán. Ya sea que las props cambien o no, en este caso, y en este caso, si la key está allí o no, en realidad no importa. Si el componente no está memorizado, se re-renderizará. La key no lo evitará. ¿Para qué la necesitamos entonces?

Imagínate en una habitación con un montón de gatitos idénticos usando diferentes sombreros. No sabes sus nombres, así que la única manera de identificarlos y describir qué gato lleva qué sombrero es por su número. El primer gato lleva una corona, el segundo lleva un sombrero de béisbol, el tercero lleva un sombrero de mago. Esto es exactamente con lo que React tiene que lidiar cuando iteramos sobre un array y renderizamos elementos secundarios. Si no los nombramos explícitamente, React no tiene manera de saber cuando renderiza este componente, si un elemento secundario es el mismo o uno completamente nuevo aparte de usar sus posiciones en el array, que es lo que usa por defecto. A menos que nombremos esos elementos secundarios explícitamente. Esto es para lo que sirve la key. Cuando asignamos esos atributos, y el componente que tiene esos elementos se re-renderiza, React detectará que los elementos secundarios son exactamente los mismos que antes. Así que todo lo que necesitaría hacer es re-renderizarlos como de costumbre. Sin embargo, si cambiamos la key en uno de los elementos secundarios, React pensará que el componente antiguo con la key igual a cero ya no está allí. Así que lo eliminará y desmontará. Y luego detectará que un nuevo componente con la key número seis aparece. Pensará que es un componente completamente nuevo. Así que lo montará desde cero. Como resultado, el resto de los componentes se re-renderizarán, pero el componente con el cambio de key se remontará a sí mismo.

Incluso si nada más que la key cambia. Y eso realmente debería responder a la pregunta de cuán única debería ser nuestra key. Si hacemos algo como esto, como generar una nueva key en cada re-renderizado, entonces en cada re-renderizado, cada uno de ellos se remontará. Esto resultará en varios errores con el enfoque y el estado. Sin mencionar que es mucho, mucho más lento que un re-renderizado normal, por lo que también tendrás problemas de rendimiento.

En cuanto a prevenir re-renderizados, la key no tiene nada que ver aquí. Necesitamos usar uno de los métodos como react.memo para prevenir que los hijos se re-rendericen. Si lo usamos, ahora el componente padre se re-renderiza y los hijos no se re-renderizarán. Pero no es por la key, es por react.memo.

Eso plantea la pregunta, ¿cuál es el punto de la key entonces si no previene re-renderizados? ¿Y por qué todos dicen que usar arrays.index como key es una mala práctica? Es por las listas dinámicas. Imagina que añadimos un nuevo elemento al principio del array. Tal vez al hacer clic en un botón que añade un nuevo elemento de tareas al principio. ¿Qué pasará aquí si usamos el índice del array como key? Se añade un nuevo elemento al principio del array, por lo que será el primero ahora. Cada elemento en este array como resultado será detectado como cambiado. Y todos ellos se re-renderizarán, incluso si están envueltos en react.memo. Sin embargo, si usamos IDs únicos que obtenemos del propio dato, entonces cuando añadimos el nuevo elemento al principio, solo el primer elemento será detectado como nuevo y montado. El resto no cambiará. Y si están envueltos en react.memo, no se re-renderizarán.

Hay mucho más que saber y entender sobre las keys y el contexto y los re-renderizados en general. Así que aquí hay algunos artículos útiles que escribí sobre los temas. Y revisa el blog en sí. Tiene muchos, muchos más patrones de React e investigaciones como esta. Y si tienes alguna pregunta o comentario, no dudes en contactarme en Twitter o en LinkedIn. Siempre estoy feliz de responder cualquier pregunta.