Scaling React: What Actually Matters

Así que, hola a todos. Soy Tathagath, y soy un líder en ingeniería de front-end con base en India. Y he estado escalando equipos y sistemas de front-end y los he lanzado. A lo largo de los años, he liderado procesos de ingeniería de UI en productos que sirven a millones de usuarios. Así que el enfoque siempre ha sido el rendimiento, la arquitectura y las mejores prácticas que permiten a los equipos moverse lo suficientemente rápido y sin sacrificar la calidad. Y por lo tanto, la charla de hoy está inspirada en esto. Y se llama Escalando React, ¿Qué es lo que realmente importa? Y probablemente, pasaremos los próximos 20-25 minutos hablando sobre algo que he observado basado en muchos equipos de ingeniería, tiempo a través de muchos equipos. Y es casi como todos los problemas que piensas que React está creando, pero en realidad no es así. Son decisiones arquitectónicas incorrectas y todas esas cosas. Así que, comencemos. Y el tema es escalando React, ¿Qué es lo que realmente importa?

Y así, primero hablaré en términos generales sobre la inspiración de esta charla, ¿verdad? ¿Cuál fue la conversación que tuve y que me inspiró a difundir esta charla? Comencemos con muchos de ustedes deben haber enfrentado el problema de que su aplicación se está ralentizando. Y deben haber sido parte de una sala de juntas donde una reunión concluye con una pregunta como, Oh, ¿deberíamos migrar de React y tal vez probar algún otro framework o biblioteca? O tal vez deberíamos simplemente reescribir toda la aplicación en cualquier framework de moda o tal vez el framework de la semana y así sucesivamente, ¿verdad? Muchos de ustedes deben haber encontrado esto en una reunión. Y sí, yo también. Quiero decir, también me encontré con lo mismo. Y lo que he descubierto es que casi cada vez resultó que React no es el problema de la lentitud de su aplicación o React no es el cuello de botella de su aplicación. Así que, esta charla es realmente sobre desglosarlo y por qué seguimos culpando siempre a lo incorrecto. React siendo lo incorrecto en este caso, pero en realidad no lo es. Así que, React no es lento, tu arquitectura lo es.

Y cubriremos brevemente un montón de problemas que parecen ser un problema basado en React, pero en realidad no es un problema de React. Es un problema que tu núcleo arquitectónico sostiene. Así que, sigamos adelante. Por qué esto importa es, de nuevo, seguí reiterando. Así que, probablemente te mostraré cinco cosas que parecen un problema de React, pero no lo son. Y al final, probablemente tendrás una lista de verificación que puedes ejecutar en tu aplicación cada lunes por la mañana para verificar si esta lista de verificación se cumple o no. Ahora, lo que ves aquí es una pirámide de rendimiento. Y cuando digo una pirámide de rendimiento, es principalmente todo lo que comprende tu aplicación, ¿verdad? Antes de ponernos demasiado técnicos, tal vez, o abordar los problemas de los que vamos a hablar, construyamos un modelo mental sobre la estructura del resto de la charla, ¿verdad? Así que, cada vez que tus aplicaciones, ya sabes, se sienten lentas, el problema reside en algún lugar de esta pirámide que estás viendo en la pantalla. En la parte superior, tenemos una capa de red, lo que obtienes, cuándo lo obtienes y en qué orden lo obtienes, ¿verdad? Luego la arquitectura, sobre cómo está organizado tu estado, cómo gestionas tu estado, cómo fluye tu información, y luego viene la pirámide de renderizado, ¿verdad? Parte de renderizado de la pirámide, que en su mayoría es manejada por el propio React. Pero también hablaremos de ello. Y luego en la parte inferior, podrías ver bucles y otras micro optimizaciones, ¿verdad? Y aquí está la incómoda verdad. Como, la mayoría de los blogs por ahí, la mayoría de los tweets por ahí, la mayoría del contenido de rendimiento de React vive en la parte inferior de esta pirámide.

Por ejemplo, el uso de use memo, envolver cosas en memo, no definir funciones dentro del render. Todas esas cosas están en la parte inferior de la pirámide. Y las mayores ganancias están en la parte superior. Y la mayoría de los equipos nunca miran allí. Optan por esto sobre la parte inferior e ignoran la parte superior. De ahí viene el cuello de botella, ¿verdad? Y los cinco problemas o cuatro problemas que vamos a cubrir hoy, cuatro de ellos viven en la mitad superior de esta pirámide, que ves en la pantalla.

Así que, sigamos adelante y pasemos al problema número uno. La sobre-renderización no es culpa de React. El lema en sí mismo te dice mucho, pero hablemos un poco sobre ello. Así que, el primer problema, la queja más común que escucho es que mi aplicación React está renderizando mucho. Está renderizando demasiado. Y eso es algo muy, muy común que escucho. Un re-render no es un problema de rendimiento. Así que, en mi opinión, React fue literalmente diseñado para simplemente re-renderizar y es bastante bueno en ello. El problema no es que React re-renderice. El problema es qué le pides que re-renderice. Así que, es una cosa diferente, dos cosas diferentes, ¿verdad? Si pones tu objeto de usuario, tomemos un ejemplo. No quiero mostrar mucho código en la pantalla porque es un poco difícil de leer. Pero probablemente intentaré relacionarlo e intentaré crear alguna analogía con lo que nosotros como desarrolladores, como ingenieros enfrentamos, ¿verdad? Así que, si pones un gran objeto de usuario y tu carrito de compras en el mismo contexto en la parte superior de tu aplicación, cada actualización del carrito volverá a desencadenar un re-render de todo lo que consume ese contexto. Así es como funciona el contexto, ¿verdad? Y eso no es React siendo lento. Esa es una decisión arquitectónica que probablemente tomaste sin darte cuenta. Así que, la sobre-re-renderización no es culpa de React. Oh sí, hace que tu aplicación sea lenta, pero no es por React, ¿verdad? Así que, ese es el problema número uno.

Vamos a profundizar en ello. Así que, hay una cosa muy famosa conocida como el patrón de difusión de contexto en React. Así que, si buscas en la web, encontrarás muchas publicaciones en Reddit, mucha gente habla sobre el problema de difusión de contexto, ¿verdad? Así que, es como cuando cambias el valor pasado a un proveedor de contexto, cada consumidor del contexto se vuelve a renderizar. No importa si el consumidor solo se preocupa por una pequeña parte de su valor. No importa porque si esa parte cambia, todos se vuelven a renderizar. Simple.

Así que, imagina que tienes un gran contexto de aplicación en la raíz, ¿verdad? Conteniendo el usuario, el tema de la aplicación, las banderas de características, el carrito, la notificación, y así sucesivamente. Entonces, cada vez que llega una notificación, cada componente que toca ese contexto se vuelve a renderizar. Tan simple como eso. Así que, esto nuevamente no es un problema de React o que React sea lento. Esto es la arquitectura de difusión siendo arquitectura de difusión, ¿verdad? Así que, eso nuevamente crea un cuello de botella.

Siguiendo adelante, hablemos de cómo podemos solucionar esto. Y ya que hablé de esto, un patrón muy común que la mayoría de nosotros debe haber visto o seguido en nuestro pasado o actualmente. Entonces, ¿cuál es la solución para esto? Así que, hablemos de la solución incorrecta, que, como mencioné, muchos blogs y muchas personas te dicen que hagas. Es envolver todo en react.memo y darlo por terminado. Hecho. Esa no es la solución correcta. Eso es exactamente, ya sabes, crear un síntoma en lugar de una enfermedad.

Ahora, la solución correcta reside en la decisión arquitectónica que tomes. Así que, por ejemplo, divide tu contexto según la frecuencia con la que se actualizan. Por ejemplo, el tema de una aplicación cambia muy raramente, pero un carrito de una aplicación cambia más frecuentemente o constantemente. Así que, no deberían ser parte del mismo proveedor. Tan simple como eso. Y para estados volátiles, por ejemplo, basados en suscripción, ya sabes, tienda, como Just Stand y etc., con esos componentes suscribiéndose a una parte del estado que quieren actualizar y quieren volver a renderizar cuando cambian, no todo el estado. Correcto.

Así que mi regla general es muy simple. Si tu reflejo, cuando ves un problema de rendimiento, es recurrir a memo, detente ahí. Pregunta por qué el componente se está re-renderizando. Usualmente la respuesta es usualmente la respuesta. Cuando digo usualmente, la mayoría de las veces la respuesta está en tu arquitectura de estado, no en tu función final.

Así que avanzando, esta es una nota muy breve sobre el compilador de React. Y estaba preparando las diapositivas. Me encontré con esto. Así que solo quería tal vez hacer un recorrido rápido sobre lo que encontré. Así que, ya sabes, esto vendrá como parte de la sesión de preguntas y respuestas en la serie posterior. Así que probablemente quería cubrirlo entre medio. Así que cuando el compilador de React alcanzó la versión 1.0 estable el año pasado, se envía con Next JS16. Lo que hace, en tiempo de compilación, es insertar automáticamente la memorización donde sea necesario. Así que, en teoría, dejas de escribir use memo y use callback a mano.

Esto es genial. Elimina una gran cantidad de trabajo ocupado. Pero, y quiero ser realmente claro aquí, el compilador no soluciona los problemas de los que estamos hablando hoy en toda esta charla. No soluciona la difusión de contexto. No soluciona las cascadas de red. No soluciona el script de terceros que infla tu aplicación. No soluciona una mala estrategia de SSL y así sucesivamente. Soluciona las cosas que ya eran un poco solucionables. Los problemas de arquitectura todavía nos pertenecen a nosotros y a ti. Right.

Así que avanzando, vamos al problema. Número dos. El problema número dos es el mal uso del estado global. Ahora, este es el error arquitectónico más común que veo. Y no se habla lo suficiente de ello. Por ejemplo, los equipos ponen datos del servidor. Quiero decir, los datos que vienen de una API en bibliotecas de estado del cliente, readups, test y móvil y lo que sea. Y gastan cientos de líneas de código reimplementando cosas que probablemente la biblioteca de obtención de datos resolvió hace años.

Por ejemplo, estado de carga, estados de error, lógica de reintento, invalidaciones de caché, ya sabes, y toda esa desduplicación, paginación, todas esas cosas ya han sido resueltas con bibliotecas de obtención de datos hace años. Así que pero pero todavía vemos muchas de estas cosas en la base de código. Tal vez hemos escrito el código. Hemos escrito la base de código, ese tipo de cosas.

Así que la gestión del estado global es un problema muy grande. Y ahora profundicemos en el estado del servidor versus cómo se ve un estado del cliente. Así que probablemente hay tres tipos de estado que categorizaría ampliamente los estados de una aplicación React en uno es tu estado del servidor. Cuando digo estado del servidor, es el dato que viene de la API que necesita caché, que necesita invalidación, reobtención, desduplicación. Y esto es lo que, ya sabes, bibliotecas como React Query, SWR, RTK Query existen. Y resuelven este propósito como que son muy buenos en ello.

Ahora viene el estado del cliente. Segundo tipo de estado que categorizaría. Entonces, el estado del cliente es el estado de la UI, como por ejemplo, un modelo que se abre, un formulario que se está escribiendo, una selección de desplegable, una selección de radio. Así que estos estados viven muy cerca de tu componente que los utiliza. Así que, por ejemplo, el estado local está mayormente bien en estos casos. Y casi nunca necesitaríamos una biblioteca para esto. Y luego viene un estado global de la aplicación. Por ejemplo, la tematización en tu aplicación es algo global o la autorización. La autenticación de la aplicación es tu estado global de la aplicación. Así que estas son pequeñas cosas, actualizaciones poco frecuentes ocurren aquí, pero necesitan ser compartidas globalmente a través de nuestra aplicación. Correcto. Y el error es contemplar estos. El mayor error es poner el estado del servidor en una biblioteca de estado del cliente, porque entonces estás reimplementando el almacenamiento en caché y la validación, creo, a mano de manera bastante mala. Así que no tiene sentido reinventar la rueda. Correcto.

Cubramos un anti-patrón clásico que probablemente se relacione con cada uno de nosotros y explicaría los estados de los que hablé. Así que digamos. Reducir o reducir slice con 300 líneas de código gestionando los datos del usuario, carga, reductor, reductor de errores, éxito, reductor, fragmento obtenido, lógica de reintento y todas esas cosas. El mismo comportamiento en React Query o SWR es tal vez 10 líneas de configuración declarativa. Eso es todo. Misma funcionalidad, mucho menos código y críticamente menos errores alrededor del estado, datos obsoletos, condiciones de carrera y dobles obtenciones. Correcto. Así que esto no es nuevamente un problema de React. Es elegir la herramienta equivocada para el trabajo y luego culpar al framework cuando el trabajo es difícil. Probablemente correcto. Así que es un anti-patrón clásico que seguimos con mucha frecuencia, o al menos he visto a personas seguir.

Pasando al problema número tres del que hablaremos hoy. Y se llama cascadas de red. Muchos de nosotros debemos haber encontrado esto, pero haría doble clic en ello y probablemente lo cubriría en un breve, breve lapso. Así que esto es, creo, probablemente el problema de rendimiento más poco discutido en nuestra industria.

Y es uno de los, ya sabes, más a menudo cuando me involucran en investigaciones de react is slow. Así que la mayoría de lo que los equipos llaman react is o react siendo lento es en realidad una cascada de red disfrazada. Así que la aplicación no es lenta porque react es lento o lo que sea, sino que es lenta porque estás haciendo que un usuario espere a través de tres viajes de ida y vuelta secuenciales que deberían haber sido uno. Un viaje de ida y vuelta, probablemente tres llamadas API secuenciales que habrían sido una. Así que eso es lo que le da a tu aplicación una cosa lenta y probablemente se llama una cascada de red. Correcto.

Así que hablemos de la trampa de fetch on render. Así que es, explicaré qué es la trampa de fetch on render. Así que cómo ocurre nuestra cascada de red. Así que es mayormente lo más natural de escribir. Digamos que un componente A se monta, lanza su propio fetch en el use effect. Los datos regresan, el componente A se renderiza, lo que hace que el componente B se monte. Luego el componente A lanza su propio fetch. Los datos regresan a B. B se renderiza. C se monta. C hace fetch. Así que tres viajes de ida y vuelta secuenciales sucediendo, el código se ve muy bonito, ordenado. Cada componente gestionando sus propios datos. Muy limpio, muy co-localizado. Correcto. Pero el usuario espera cuatro segundos porque cada fetch solo puede comenzar después de que los datos anteriores regresen. Así que es una obtención secuencial, haciendo que el usuario espere una cantidad decente de tiempo que podría haber sido, ya sabes, menos. Así que esta es la trampa de fetch on rendered mayormente. Estoy dando el premio a la cascada de red. Este es un ejemplo de código muy rápido de muy. Esta es la versión del error que todos han enviado en algún momento de, ya sabes, su carrera. Y así que si ves el ejemplo a la izquierda, son tres awaits en fila. Cada uno, digamos, espera a que, ya sabes, el anterior termine. Y luego si cada llamada toma 200 milisegundos, el tiempo total es de alrededor de 600 milisegundos.

Así que el cuello de botella es el tercero de ellos. Y puedes ver que el cuello de botella no es el tercero de ellos. Lo siento. El cuello de botella es el más lento de ellos que, ya sabes, toma tu tiempo. Así que en el lado derecho, si ves, hay una promesa para todos que solicita que las tres peticiones se disparen a la vez. Así que el tiempo total es cualquiera que sea el más lento, probablemente en todos estos tres casos, digamos que 200 milisegundos es el tiempo que cada uno toma. Probablemente 200 milisegundos es el tiempo que tu usuario total espera en la pantalla. Así que los mismos datos, pero el tiempo es más rápido. Y esta es la versión trivial del problema. La versión difícil es cuando la cascada está oculta a través de múltiples componentes y no puedes verla sin abrir tu pestaña de red.

Y por lo tanto, todos nosotros aquí estaríamos de acuerdo con el hecho de que cuando estamos desarrollando algo, la pestaña de red es algo que siempre está abierta en el, ya sabes, como parte de nuestro elemento de inspección. Así que esto es lo que y es muy fácil equivocarse aquí porque el código parece muy ordenado al principio.

Ahora, me gustaría hablar sobre cómo, ya sabes, arreglarías las cascadas a nivel muy arquitectónico. Y no es que arregles las cascadas componente por componente, las arreglas a nivel arquitectónico. Cuando digo, por ejemplo, mover datos, mover la lógica de obtención de datos al nivel de ruta, cargadores en, por ejemplo, Tankstack router o tal vez React router, componentes de servidor en Next.js, la idea es la misma. Iniciar las obtenciones antes de que el componente que necesita los datos incluso se monte. Esto se llama renderizar mientras obtienes. Correcto. Comienzas la obtención primero, luego renderizas. Suspense, por ejemplo, te permite leer de las promesas en vuelo. Así que el componente puede declarar su dependencia de datos sin siquiera iniciar la obtención por sí mismo. Así que, en resumen, antes de culpar a React por una página lenta, abre la pestaña de red. Si ves una escalera, entonces esa es la cascada. Y eso no es todo un problema del framework. Es nuevamente un problema de la forma en que arquitectamos la aplicación.

Correcto. Así que vamos a pasar al problema número cuatro. Y son los scripts de terceros. Así que este es el éxito inesperado de la charla.

Y no nos damos cuenta hasta que lo vemos. Incluso si hablo de mí mismo, no me doy cuenta de que los scripts de terceros pueden ser culpables. Hasta el punto en que realmente vi que esas cosas se convertían en un cuello de botella. Y probablemente estoy de acuerdo en el hecho de que todos en esta sala están sufriendo por ello. Así que el código de tu aplicación probablemente no está tan inflado. Pero déjame mostrarte algunos números. Correcto.

Antes de que incluso lo seas. Así que estos números son, nuevamente, he mencionado las fuentes, pero estos números son del archivo HTTP, que mide la web real. Correcto. Y la página web promedio carga más de treinta y cinco scripts de terceros y treinta y cinco. Ese es un número bastante grande. Correcto. Y un solo script de terceros puede bloquear tu página de renderizarse.

Así que eso es lo masivo de una carga de script de terceros sin que lo sepas. Y el tiempo de bloqueo promedio para Drop y la mayoría de los scripts de terceros populares está alrededor de uno punto cuatro segundos. Y de nuevo, ese tiempo de bloqueo de uno punto cuatro segundos es bastante grande. Y de nuevo, eso no es, ya sabes, el problema de tu código React. Eso no es tu empaquetador. Pero eso es una etiqueta que tu equipo de marketing te pidió que agregaras hace 18 meses. Y ahora ves eso en acción, creando cuellos de botella reales en nuestras aplicaciones.

Así que diría, ya sabes, muerte por mil etiquetas. Así que tratemos de visualizar una aplicación de producción donde tenemos un SDK de analíticas, una herramienta de repetición de sesión como, ya sabes, full story o hot jar y un widget de chat, un SDK de banderas de características, tal vez una herramienta de pruebas A/B, un gestor de etiquetas que carga más etiquetas dinámicamente. Cada uno de estos, ya sabes, en una fecha fue agregado, parece pequeño. Es solo una etiqueta. Se carga de manera diferida. Es asíncrono. Pero solo apílalos y superan el código de tu aplicación. Por lo tanto, nuevamente, convirtiéndose en un cuello de botella. No puedes culpar completamente a tu código de aplicación. Son scripts de terceros que te pidieron que pusieras sin siquiera, ya sabes, previsualizarlos.

Ahora viene. Hablemos de una parte muy dolorosa. Está bien. Está bien si cometemos estos errores. Pero ¿cuál es el costo de cometer estos errores? Correcto. Así que y es el patrón que discutiremos aquí. Es mayormente un patrón consistente y es tan consistente que es casi gracioso. Así que tomemos un ejemplo del equipo de ingeniería que pasa un trimestre completo optimizando el paquete. Hacen división de núcleo. Hacen carga diferida, reemplazando el momento con data finesse y eliminando importaciones de barril. Y reducen el paquete en un par de cientos de kilobytes y celebran. Eso es un gran logro, en mi opinión. Correcto.

Pero dos semanas después, marketing añade, añade una nueva etiqueta por la tarde. Y las ganancias de rendimiento se evaporan. Nadie conecta los dos eventos. La ingeniería es culpada de que la aplicación sea lenta de nuevo. Así que probablemente esto es, ya sabes, un problema de gobernanza disfrazado de un problema de rendimiento, en mi opinión. Correcto.

Y. ¿Qué deberías hacer, en realidad, ya sabes, probablemente cuál debería ser la la la forma o la la estrategia para evitar estos. Así que probablemente cinco cosas y estas no son opcionales, en mi opinión, si realmente te importa el rendimiento del usuario. La número uno es que la ingeniería tenga el presupuesto de terceros. No es solo decisión de marketing. Si se añade una nueva etiqueta, la ingeniería necesita revisarla. Y número dos, carga diferida de scripts no críticos. Cualquier cosa que no necesite activarse en el primer panel debería esperar, no debería bloquear nada.

Número tres, auditorías trimestrales. Cada etiqueta tiene que justificar su peso. La mayoría de ellas no pueden porque cargan muchas cosas innecesarias en ella y la cargan. Pero tienes que hacerlo. Y ahí es donde entra la verdadera ingeniería. Como, deberías saber qué está corriendo en tu navegador. Deberías saber qué está corriendo dentro de tu aplicación. Correcto. Número cuatro. Tal vez rechazar la solicitud de simplemente añadir esta solicitud de etiqueta con datos. Así que lo que cuesta en tiempo de carga, números, cuando estos argumentos y digo números en este argumento, Yo personalmente, ya sabes, he luchado o he rechazado estas cosas. Y si tengo un punto de datos para justificarme, está absolutamente bien. Y número cinco, incluir los impactos de terceros en tus paneles de rendimiento, lo cual la mayoría de nosotros usualmente no hacemos. Pero si solo mides tu propio código, estás perdiendo el mayor costo. Como muchas cosas suceden detrás de escena en estos scripts de terceros. Correcto.

Y pasemos al problema. Número cinco. Y lo llamo SSR, SSR mal aplicado. Y este es un error de moda de los últimos años. Correcto. Los equipos adoptan NextJS o Remakes esperando alguna magia de la caja. Activan el interruptor en SSR y a veces envían una aplicación más lenta de la que tenían antes. Así que esto no es magia. Pero créeme, SSR no es magia. Es una herramienta con costo y aplicarla sin entender el costo es probablemente, ya sabes, cómo haces las cosas más lentas mientras te sientes más sofisticado. Correcto.

Y vamos a sumergirnos en los errores comunes de SSR que usualmente cometemos. Y probablemente he visto cuatro patrones constantemente. El primero es. Así que renderizar páginas que deberían haber sido estáticas, si el contenido no cambia en cada solicitud, no veo la necesidad de un SSR, probablemente es un caso de SSG o ISR, pero estamos sobreutilizando o matando el renderizado SSR. Correcto. No hay necesidad de ello. El número dos es la obtención de datos del cliente además de los datos del servidor. Por ejemplo, obtienes en el servidor, lo renderizas y lo envías al cliente. Luego obtienes los mismos datos nuevamente en el use effect. Eso probablemente es una doble obtención, el doble de trabajo. Nuevamente, una trampa, nuevamente, un error común.

Número tres, marcar todo como un componente del cliente en una aplicación de componentes del servidor. Simplemente poner un use client en todo te da el costo de SSR sin ningún beneficio. Sí. De todos modos, estás enviando un, ya sabes, un JavaScript. Eso es todo. Así que escribir ciegamente use client en la parte superior de tu archivo no tiene ningún sentido. Es simplemente algo que mata tu aplicación. Número cuatro.

Y el último, el error más común que he visto es ignorar el costo de la hidratación. Ahora, ¿qué es la hidratación? Es un proceso donde tu aplicación React toma el servidor y un HTML y adjunta un listener de eventos para hacerlo más interactivo.

Pero no es gratis. La hidratación no es gratis.

Y, por ejemplo, en un teléfono Android de gama baja, puede ser muy, muy brutal. Así que probablemente categorizaría los errores comunes, ya sabes, en estas cuatro categorías.

Vamos a hacer doble clic en ello. Estaba leyendo un blog del equipo de ingeniería de VIX y me gustaría destacar una frase muy buena que encontré. Probablemente publicaron un blog sobre esto el año pasado, en noviembre o octubre. No recuerdo el momento, pero están bajo cientos de millones de páginas. Aman SSR y están diciendo en voz alta que la hidratación se convirtió, en sus palabras, en un impuesto que no podían ignorar. Y esto es del propio equipo de ingeniería de VIX. Y siento que es una validación a prueba de balas, ya sabes, una validación sólida de la afirmación de la que hemos estado hablando en los últimos errores de SSR.

Así que varios componentes cambian este cálculo. No envían código de implementación al cliente en absoluto. Menos código para hidratar. Pero solo obtienes ese beneficio si entiendes el límite servidor-cliente y lo usas intencionalmente. Correcto. Y así, las herramientas sofisticadas no hacen que las aplicaciones lentas sean rápidas. Entenderlas sí lo hace. Y. Siguiendo adelante.

Así que el patrón en los cinco probablemente sea menos, tal vez dar un paso atrás, retrocedamos y veamos qué hemos descubierto hasta ahora. Así que sobre renderizado, problema número uno, mal uso del estado global, cascadas de red, sobrecarga de terceros, SSR mal aplicado. Y si ves cuidadosamente, ninguno de ellos o ninguno de estos son problemas reales, todos estos son decisiones, decisiones que tú y yo tomamos son los verdaderos cuellos de botella. Así que React está haciendo exactamente lo que le dijiste que hiciera. El framework de la biblioteca está renderizando lo que le pediste que renderizara. Entonces le pediste que renderizara. La lentitud no proviene de React. Proviene de la arquitectura que tú y yo construimos sobre ella. Así que probablemente el plan es que deberíamos empezar a pensar como un arquitecto.

Así que si hay un cambio de mentalidad que quiero que te lleves de esta charla, es dejar de preguntar si React es lo suficientemente rápido. Esa es la pregunta equivocada. React es absolutamente lo suficientemente rápido. Empieza a hacer preguntas de arquitecto. Por ejemplo, ¿qué estoy obteniendo y cuándo quién posee el estado y por qué es global? ¿Qué se está re-renderizando y qué realmente se suscribe a ello? ¿Qué hay en mi paquete que no escribí? Probablemente típicos scripts de terceros. ¿Qué estoy renderizando en el servidor y por qué? Creo que estas preguntas, estas son las preguntas que mueven el rendimiento y no debería usar memo aquí. Correcto. Así que como prometí manejar una lista de verificación de lunes, lista de verificación de lunes por la mañana para todos, daría esto como una lista de verificación. Y esto es algo concreto que, por ejemplo, pestaña de red. Así que abre la pestaña de red, mira la carga de tu página más importante. ¿Es una escalera o una ráfaga paralela? Si es una escalera, tienes una cascada. Número dos, abre tu perfilador de herramientas de React, haz clic a través de eso, haz clic a través de tu aplicación. ¿Qué se re-renderiza en cada interacción? ¿Estos componentes se re-renderizan sin razón? Si es así, revísalo. Número tres, ejecuta un analizador de paquetes. Mira la sección de terceros. ¿Quién posee esos scripts? ¿Puedes justificar cada uno de ellos? Si es así, adelante. Si no, probablemente necesites revisarlo. Número cuatro, lista todo en tu estado global. ¿Cuánto de eso es realmente estado del servidor pretendiendo ser estado del cliente? Esa es una verificación muy, muy importante que necesitamos, ya sabes, revisar. Y por último, pero no menos importante, encuentra tu contexto más grande. Correcto. ¿Y con qué frecuencia cambia su valor? ¿Qué tan grande es el subárbol debajo de él? Así que probablemente por mi experiencia, definitivamente encontrarás algo embarazoso dentro de la primera hora de esto, ya sabes, pasando por la lista de verificación. Lo garantizo. Así que esa es la lista de verificación de lunes por la mañana para ti. Y antes de cerrar, la conclusión honesta. Si haces todo eso y realmente haces todo eso y React sigue siendo tu cuello de botella, entonces creo que felicitaciones. Has ganado el derecho de considerar una migración. Pero en mi experiencia, casi nadie llega a eso. Casi todos los equipos que pensaron que React era el problema encontraron otra cosa cuando miraron muy cuidadosamente y React no es el cuello de botella. Las decisiones alrededor de él probablemente piensan como un arquitecto, no un usuario de framework, un usuario de biblioteca. Y la próxima vez que alguien esté en una reunión, diga que deberíamos migrar, probablemente pregúntales qué hay en su pestaña de red. Así que gracias. Y espero que esto haya tenido mucho sentido para la audiencia allá afuera. Y estos son los manejos con los que puedes, ya sabes, tal vez ponerte al día, ponerte al día conmigo en Twitter y LinkedIn para cualquier cosa en la que quieras participar.