Compilador React Forget - Entendiendo React Idiomático

Entonces, sí, soy Joe. ¿Esto es demasiado fuerte? Parece fuerte. Bueno, está bien. Entonces, soy Joe. Soy un ingeniero en el equipo de React en Meta y en esta charla nos gustaría compartir nuestra visión para el desarrollo de React en el lado del cliente, específicamente estoy hablando de React Forget. Forget es un compilador que hemos construido en Meta que memoriza automáticamente tus componentes y hooks. Así que si esperabas que hiciéramos open source a Forget hoy, lamento decepcionarte. Pero hemos avanzado mucho y estamos emocionados de compartir más sobre eso contigo hoy.

Entonces, voy a hablar sobre cuál es nuestra visión, qué es Forget y cómo se ajusta a esa visión. Y luego Mofe va a subir y hablar sobre nuestro progreso en la implementación de Forget en Meta.

Para entender nuestra visión para React, ayuda mirar un poco de código. Aquí estoy mostrando una versión simplificada de un componente interno de Meta. Este componente toma un encabezado, una lista de videos y un filtro. Y luego renderiza el encabezado y la lista de videos que coinciden con ese filtro. Puedes imaginar que el componente real es más complicado. Ya sabes, los filtros son en realidad estado, etc. Es una versión simplificada. Personalmente, creo que hay mucho que me gusta de este código. Es un componente pequeño, claro y conciso. Utiliza valores de JavaScript simples, arrays. Usamos la sintaxis estándar de JavaScript, if-else para condicionales, un bucle for para iteración. No necesitamos aprender algo nuevo, esto es solo el JavaScript que ya conocemos. Usa la plataforma.

Entonces, en muchos aspectos, esto es React en su mejor momento. Usamos esta UI como una simple función de data. Realmente solo hay un problema potencial con este código. Si lo enviamos tal cual, podríamos ver partes de nuestra aplicación rerenderizadas innecesariamente, y eso puede afectar el rendimiento, ralentizando las cosas. Veamos un ejemplo de cómo puede suceder eso. Imagina que nuestro componente se vuelve a renderizar, pero solo el encabezado ha cambiado realmente. Cuando el componente se renderiza, pasa ese nuevo encabezado al componente de encabezado, que se actualiza como esperábamos.

Pero eso no es todo lo que sucede por defecto. Cuando nuestro componente se vuelve a renderizar, todo el componente se vuelve a ejecutar. Esta función completa se vuelve a ejecutar. Eso significa que creamos una nueva lista de videos filtrados, y luego pasamos eso a video list, que luego también se vuelve a renderizar todo el camino hacia abajo del árbol. Y esto sucederá todo el camino hacia abajo del árbol. Aunque nada cambió significativamente sobre los videos.

Para abordar esto, podemos usar dos APIs de React, usememo y react.memo. Así que aquí, he aplicado usememo a la lógica para filtrar los videos. La matriz en la parte inferior aquí le dice a React que solo vuelva a calcular los videos filtrados si los videos o los valores del filtro han cambiado realmente. Así que ahora si solo cambia el encabezado, no volvemos a calcular la lista de videos filtrados. Genial. Pero eso no es suficiente. Porque aunque estamos pasando los mismos videos filtrados al componente de la lista de video, por defecto, React seguirá volviendo a renderizar un componente, incluso si sus props no han cambiado. Para optar por no hacer eso, envolvemos el componente con react.memo. Así que ahora obtenemos el rendimiento esperado con estos dos cambios. Ahora cuando cambia el encabezado, no tendremos que actualizar el componente de la lista de video. Genial.

Pero si aplicas juiciosamente React use memo, use call back, que es una especie de call back versión de use memo, y luego react.memo, si los usas de manera consistente en tu base de código, puedes lograr un muy buen rendimiento con React. Y muchos otros presentadores han hablado de eso antes. Hemos encontrado que generalmente cuando las aplicaciones tienen un problema de rendimiento, es porque de esta especie de memoización faltante y puede ser solucionado simplemente añadiendo esto de vuelta. La memoización ha hecho que nuestro código original sea mucho menos conciso y claro. Ya no estamos simplemente describiendo lo que la UI debería estar mostrando. Tenemos que decirle a React cómo procesar nuestro código. Eso es un poco perder la idea original de React, ¿verdad? Renderizado declarativo. Pero ahora tenemos que entrar en el cómo. Y luego nuestras revisiones de código se convierten en si hemos memoizado correctamente, si hemos memoizado demasiado poco, demasiado. Tenemos posts en blogs diciendo que no deberías memoizar en absoluto, que no necesitas memoización. Y lo cierto es que ambos tienen razón, porque todo depende del contexto. Este código, el código original aquí podría estar bien en muchas aplicaciones. Pero para otras aplicaciones podrían tener un problema de rendimiento.

Pero realmente, con esta memoización, nuestro código se llena de lógica extra. No nos estamos enfocando solo en la experiencia del producto central, sino que volvemos a centrarnos en cómo lograrlo. Esto hace que nuestro código sea más difícil de leer y de cambiar. Entonces, en cierto sentido, useMemo es un compromiso.

Sacrificamos algo de la lógica original limpia y concisa a cambio de un mejor performance. Pero, ¿por qué necesitamos hacer este compromiso en absoluto? Bueno, volvamos al código. La razón por la que comenzamos este camino fue que necesitábamos usar useMemo para decirle a React que la lista de video no depende del encabezado. Pero todos somos desarrolladores, conocemos JavaScript, ¿verdad? Ya le hemos dicho a React que la lista de video no depende del encabezado. De hecho, hemos utilizado un formato de instrucciones muy bien especificado que las computadoras ya entienden para darle esa información a React. Se llama JavaScript. Ya lo conoces, ¿verdad? Entonces, ¿por qué tenemos que decirle a React de nuevo? ¿Por qué también tenemos que agregar en nuestro useMemo para decirle a React, oh, esto no depende de estos valores? ¿Qué pasaría si React pudiera averiguar eso automáticamente? Y mejor aún, ¿qué pasaría si React pudiera averiguar esto en tiempo de compilación cuando compiles tu aplicación? ¿Y si no lo hiciste?

...decisiones de design, pero es posible que necesitemos hacer ajustes y optimizaciones adicionales, dependiendo de los data. Nuestro próximo paso es escalar hasta que Forget se use en todas partes en Meta, refinando pequeños detalles. Finalmente, cuando hayamos probado y iterado lo suficiente, lanzaremos. Aunque todavía tenemos trabajo por delante, creemos firmemente que Forget ayudará a React a lograr su visión, una experiencia de desarrollador ergonómica, junto con un gran rendimiento. Gracias.

Vamos a saltar directamente a las preguntas del público. Así que espero que estés listo. La primera pregunta con más votos es ¿esto elimina completamente la necesidad de useMemo, memo y useCallback? Sí, a largo plazo, la idea es que nos gustaría eliminar completamente esas APIs. Obviamente, es un largo camino para llegar allí. Pero ese es el objetivo, sí. Genial. Eso es agradable. Es uno, en mi experiencia, uno de los conceptos más difíciles de entender. Pero sí, algo que necesitas entender si estás construyendo una gran aplicación. Así que super agradable. ¿Cómo hace React... ¿Por qué se llama React Forget y no React Remember? La pregunta anterior fue muy buena. Estaba emocionado por eso. Quería responder a eso. Bueno, sé lo que era.

Vamos a llegar a eso. Oh, está bien, está bien. De acuerdo. ¿Por qué se llama React Forget? Entonces, tenemos una política de nombrar todas las cosas con palabras que comienzan con F que son juegos de palabras, y entonces remember no es, sí, no es una palabra que comienza con F. Bueno, es justo. Nos gustan las palabras que comienzan con F. ¿Dan? Somos neoyorquinos. No se permite maldecir en el escenario. Yo no lo dije. Adelante.

Siguiente pregunta. La mejor pregunta. De David. ¿Cómo sabe React Forget cuándo no aplicar innecesariamente memoizaciones, como cuando la memoización es más costosa que no hacer ninguna memoización en absoluto? Entonces, hacemos dos cosas aquí. Lo primero es el análisis de escape. Miramos los valores que realmente se devuelven de la función, como de JSX, o los valores que se pasan a los hooks como entradas. Así que solo memoizamos los valores que finalmente salen de la función. Lo segundo es que hacemos una inferencia de tipos para no memoizar primitivas. Entonces, cosas como array.length, por ejemplo, podemos inferir que es una primitiva. Y dado que eso no va a causar un re-renderizado innecesario en los hijos de React, actualmente optamos por no memoizar esos. Genial, gracias.

La siguiente pregunta es, mencionaste que Forget es para React del lado del cliente. ¿Cómo encaja este proyecto en el cambio de paradigma de los componentes del servidor de React? ¿Quizás Forget jugará un papel más grande en React Native? Sí, esa es una gran pregunta. Así que no vemos que React del lado del cliente desaparezca. Los RSEs expanden React. No disminuyen la necesidad de React del lado del cliente para manejar las partes interactivas de tu aplicación. Y entonces, para las partes de tu aplicación que siguen siendo interactivas, Forget ayuda a hacerlas más rápidas por defecto y mejora la experiencia del desarrollador allí. Pero creo que la otra parte es que Forget es un compilador para React. Y así que lo primero que estamos haciendo con ese compilador es optimizar la experiencia del desarrollador del lado del cliente. Pero tenemos otras ideas sobre cómo construir sobre el análisis que Forget está haciendo.

Por ejemplo, tal vez haciendo compilaciones de servidor optimizadas. Si estás haciendo SSR, Forget podría descubrir que el estado de uso no se va a ejecutar en un entorno SSR y eliminarlo. Y luego podrías hacer algo de eliminación de código muerto desde allí y tener un servidor más optimizado construir. Así que tienes más ideas para qué hacer dado esta plataforma de compilador en el futuro.

Genial, gracias. La siguiente es una pregunta de Dennis Kroekneet. ¿Por qué no hacerlo open-source para que podamos mejorarlo como community? Sí, lo haremos cuando esté listo para open-source. Creo que Mofay, tú cubriste eso, ¿verdad? Y creo que en la última diapositiva realmente me gustó el tipo de etapas por las que pasamos. Creo que tenemos acceso único a científicos de data. Sí y como no sé si quieres... Sí, y creo que no hay mejor prueba de estrés que la escala de Facebook, ¿verdad? Así que todos los que quieran mejorar, no van a tener, o la mayoría de ellos no van a tener la escala que ustedes pueden tener para pruebas de estrés. Sí, siento que quieres compartir más sobre, no sé si hay algo más que quieras compartir, como lo que hemos pasado internamente solo para mirar en. Tienen un código bastante loco en Facebook. Tenemos miles de ingenieros escribiendo código durante una década en este punto, casi una década. Hemos visto casos de uso realmente interesantes y esperamos que al menos toda nuestra experiencia implementando Git en Meta solo lo haga mejor para la comunidad de código abierto community. Sí. Sí. ¿Y eso es algo... Cuando estás desarrollando esto, ¿es algo como, siempre está construido para Meta o es algo que realmente tienes en cuenta entonces, como esto también para el resto de la community? Porque Meta está pagando las facturas, por supuesto, así que lo entendería completamente.

Sí. Pasamos mucho tiempo pensando en nuestra estrategia de lanzamiento de código abierto. Entonces, durante los últimos, no sé, un par de meses, hemos... Whoa. Eso es mucha gente. Oh. Estamos probando Git en aplicaciones de código abierto también. Usa Git y aplicaciones como usando otros frameworks como Remix, Next.js solo para asegurarte de que encaja en el pipeline. Sí. Sí. Eso es genial escuchar.

Gracias. Próxima pregunta de Metin Parzhinski. ¿Es esto algo que tendremos que instalar, o simplemente estará en la versión X de React? Es parte del pipeline de construcción, por lo que es algo que tendrás que instalar. Hay una pequeña dependencia, y depende de una API adicional de runtime en React. Por lo tanto, requerirá en algún momento que salga en una versión estable de React. Y una vez que hayas actualizado a esa versión de React, podrás agregar el plugin de Babel.

Sí. Vale. Genial. Bueno, la pregunta que sabíamos que vendría, ¿cuándo se lanzará React para Git? Creo que Mofe lo describió en su sección de la charla. Así que definitivamente consulta la charla, y repasamos los pasos que nosotros atravesamos, prototipo inicial, iteración, refinándolo en más y más productos que Meta, y luego lanzándolo. Como mencionaste en la charla, nos exigimos un nivel muy alto, ¿verdad? Pero no solo la calidad de lo que estamos lanzando, sino cosas como la documentation, estar disponible para responder a preguntas de soporte, ser capaz de revisar realmente las solicitudes de extracción que corrigen errores. Así que queremos, cuando sea de código abierto, queremos que sea realmente un buen proyecto de código abierto. Pero eso requiere trabajo de nuestra parte que nos quitaría tiempo para terminar Forget y hacer lo que necesita ser. Así que creemos que lo correcto a hacer ahora es realmente hacer que Forget sea tan impresionante como pueda ser para que esté listo para salir al código abierto.

Muy bien. Así que todos pueden olvidarse de React, olvidar hasta que se lance. Ese es el mensaje, sí. Pero muchas gracias por esta introducción. Perdimos la noción del tiempo. Se suponía que debíamos terminar hace cuatro minutos. Así que muchas gracias por estar aquí. Sí, gracias. Y vamos a continuar con la siguiente parte.