Panel Discussion: The State of React

Sí, soy Evan Bacon, soy el creador de Exporouter, trabajo en Expo, React Native, desarrollo móvil, React Native Web, empaquetado. Soy Tanner Linsley, hablé hace una hora. Creé TanStack. Soy Sascha Grief, realizo encuestas para desarrolladores, incluyendo el estado de React sobre la comunidad de React. Soy Shruti Kapoor, también di una charla hace unos minutos. Soy creadora de contenido a tiempo completo, hablo sobre React e IA. Hola, soy Naman, creé Stylex, hice algunos trabajos en React. Hablé, hice una alternativa a React para mi charla. Mi nombre es Jarrod, trabajo en Bun.

Bien, genial. Así que creo que es seguro decir que un tema que ha sido recurrente sobre React hoy, incluso ayer en nuestras discusiones, son los RSCs. Y Mark, ya has hablado mucho sobre ellos. Tanner, también fueron parte de tu charla un poco. Y me pregunto si hay otros panelistas que tengan cosas que agregar sobre los RSCs.

Una cosa que me ha dado curiosidad es, en primer lugar, ¿quién los ha usado realmente en producción? Levanten la mano. Entonces, ¿cuenta un sitio web personal? ¿Producción? Supongo. Veamos, ¿como para tu trabajo diario en una empresa en producción? No. Bien. Producción. Así que eso ya es un punto de datos interesante, creo. Me gusta realizar encuestas, así que esa fue una pequeña encuesta. Una buena encuesta improvisada justo ahí. Pero bien. Así que incluso si no los has usado en producción, ¿alguien tiene algo que quiera agregar sobre ese tema? Así que tengo un par de pequeños pensamientos. Uno es, hay algunos otros marcos que ya tienen implementados los RSCs y la gente parece no hablar de ellos. Las personas que han usado Waku dicen que es realmente agradable y divertido y más suelto, porque Next.js es un marco más estructurado y tiene una arquitectura y Waku es como haz lo que quieras. Y nadie habla de ese. Está Redwood, como rwsdk acaba de lanzarlo. Nadie está hablando de eso. Y tal vez solo necesitamos que más personas prueben esas cosas para expandir lo que la gente piensa de los RSCs.

¿Más variedad, dirías? {{^}}Más variedad, sí. Así que creo que fue una de las preguntas que tuvimos antes, pero ¿qué ha estado impidiendo la adopción de componentes de React? ¿Alguien quiere intentarlo? Comenzaré yo. Así que en realidad dirigí un panel en React. Voy a olvidar el nombre. Pero en San Francisco, también dirigí un panel allí, y hablamos sobre lo mismo. ¿Qué son los RSCs y por qué adoptarlos? Y creo que desde entonces, y hasta ahora, he visto el mismo patrón común, que es es difícil primero entender qué son los RSCs. Pero también, una vez que los entiendes, adoptarlos ha sido difícil también. Y la pequeña porción donde realmente puedes usar RSCs y tienen el tipo correcto de ventaja es pequeña. Así que la adopción, por lo tanto, ha sido muy baja. Por ejemplo, en Slack, queremos adoptar RSCs. Pero no tenemos Next.js. Entonces, ¿cómo seguimos ese camino? Lo encuentro como una de las cosas más difíciles sobre adoptar RSCs.

Sí, bueno, agregamos soporte de componentes de servidor a Expo experimentalmente al comienzo de este año, y ha sido bastante bueno hasta ahora. Quiero decir, en nativo, no hay obtención de datos. Hay tanta variedad para la obtención de datos en la web, y tenemos muy poco en nativo, así que es impactante pasar de nada a este sistema realmente comprensivo y detallado granular. Y uno de los beneficios que vemos de esto es que es realmente, como, un primitivo universal para SSR, SSG. Es un sistema que puedes aplicar tanto a nativo como a web simultáneamente. Y cuando miramos, ya sabes, personas tratando de compartir código, es bastante sencillo compartir código de componentes, estilos, tal vez incluso interacciones. Pero luego, si tienes que empezar a bifurcar a nivel de enrutador o si tienes que bifurcar entre plataformas a nivel de obtención de datos, como funciona la autenticación, entonces todo se desmorona. Es tan fundamental. Y así, con RSCs, realmente tenemos una oportunidad de construir una obtención de datos universal que funcione de una vez y simplemente se ejecute de manera bastante agresiva en todas partes, lo cual encontramos realmente agradable en nativo. También podemos hacer, como, pequeños trucos donde, ya sabes, como, el payload de RSC, necesitas transmitir eso a través de, como, un renderizador HTML en la web. En nativo, puedes simplemente hacer que el tiempo de ejecución nativo interprete RSC esencialmente como, como, HTML nativo. Y así obtienes esta versión más pura de, como, una especie de navegador React-first.

¿Crees que hay un costo en el hecho de que React no nació con RSCs y es algo que vino después en comparación con algo como, no sé, Astro tiene. No es lo mismo, pero fue construido desde el principio con esa perspectiva de tener la arquitectura de isla. ¿Hay un futuro tal vez algún nuevo marco que vaya a integrar ese concepto desde el principio? Así que, quiero decir, creo que es principalmente un problema de integración, que es, como, vi cosas muy similares incluso con Stylix donde, como, una vez que todo está configurado, probablemente sea divertido y agradable de usar, pero configurarlo es, como, una cosa tan difícil que una vez que te quedas atascado en el paso uno, nunca lo usarás. Y creo que hasta ahora, como, Beats no ha enviado integración y, como, Webpack fue el único, e incluso esa integración no fue, como, una implementación súper limpia, fácil y portátil. Así que creo que simplemente las herramientas no se han puesto al día todavía. Así que en Bund, en realidad esto no está documentado, y no hemos trabajado en ello en, como, seis meses, pero en realidad tenemos una integración de componentes de servidor de React.

Básicamente está en un estado muy incompleto. Puedes usarlo si eres lo suficientemente aventurero. Si pasas dash dash app a Bund build, tiene un enrutador de sistema de archivos, puedes hacer el back end, como, plantillas con JSX de la manera que esperarías que funcione. Esto es algo en lo que eventualmente queremos hacer un trabajo mucho mejor, pero honestamente, ahora mismo, estamos, como, muy enfocados en la compatibilidad con node, así que realmente no podemos dedicarle tiempo, pero es algo que creo que desde una perspectiva de tiempo de ejecución, como, la superposición del Bundler con el tiempo de ejecución hace que probablemente podamos tener una experiencia bastante buena aquí. Realmente enfocados en hacerlo más simple para hacer las partes de renderizado del lado del servidor de una manera que realmente tenga sentido sin tener que hacer el paso de hidratación. Todavía no estamos allí.

Sí, eso es interesante, y al menos hablando personalmente, creo que uno de los beneficios de los componentes de servidor, al menos de la forma en que se presentó inicialmente, fue simplificar parte de tu código. Tal vez puedas hacer una consulta a la base de datos directamente desde tu componente, pero cuando realmente implementé RSCs, me encontré con muchos casos límite, como podrías esperar, lo que significaba que mi código no se simplificó realmente. Más bien lo contrario. Así que me pregunto si tal vez los componentes de React no fueron, como, vendidos de la manera correcta, y todavía lucho por articular la razón por la que deberías siquiera preocuparte por ellos y usarlos. Tengo curiosidad si alguien realmente puede hacer ese caso, como, asumiendo que superamos todos los problemas de si deberías usar un marco o no, asumiendo que alguien quiere subirse a bordo y está abierto a eso, ¿cómo vendes la idea de los RSCs?

Es una respuesta un poco barata, pero la respuesta corta es ve a leer el blog de Dan Abramov, porque ya ha escrito una docena de publicaciones sobre este tema con más detalle del que cualquiera de nosotros podría hacer. Lo ha estado abordando desde la perspectiva de si conoces las APIs REST, aquí está cómo los componentes de servidor son diferentes y mejores que las APIs REST. Si vienes de un fondo de GraphQL, si vienes de una mentalidad diferente, aquí es cómo los componentes de servidor llegan allí. Está repitiendo lo mismo de diferentes maneras, pero está haciendo las comparaciones para que tengas un trasfondo familiar desde el cual comenzar, así como mostrando, pero si haces una API REST, sigues teniendo que agregar todos estos campos adicionales que la UI necesita para sus solicitudes, o podrías simplemente usar un componente de servidor y formatear los datos y enviarlos hacia abajo. Creo que genuinamente la mejor respuesta aquí es leer el blog de Dan. Él ha hecho esas explicaciones, y ahora no tenemos que hacerlo nosotros. ¿Así que estás diciendo que deberíamos invitar a Dan el próximo año? También eso.

¡Aplaudan si quieren a Dan! Ojalá alguien pueda mostrarle el video. Una cosa que realmente me gusta de los componentes de servidor es, al igual que cuando llegué a React, es simplemente increíble. Ahora hay tantos frameworks composables, pero en ese momento era como... La composabilidad era realmente inigualable en React en el lado del cliente, así que es realmente emocionante pensar en un mundo donde podrías tener ese mismo nivel de composabilidad para tu servidor nivel, tu backend para frontend, donde alguien podría construir un producto y expresarlo completamente como un componente de React. Casi como cómo eran los plugins de WordPress por un tiempo. Podrías simplemente... Puedo ver una startup de YC, probablemente ya hay algunas, que son como, aquí está cómo usas nuestro producto, como npm install este componente, colócalo, y eso es como todo el SaaS. Colocas tus variables de entorno, y listo. Así que ese nivel de composabilidad es muy emocionante, y solo la oportunidad allí para que la gente inicie una idea realmente compleja con la simplicidad que obtienes con React. Todavía no estamos allí, por cierto, pero ya sabes, uno de estos días.

No sé si alguien tiene más que agregar sobre los componentes de servidor. Quiero decir, una de las cosas que no se menciona, como cuando los componentes de servidor, cuando primero vi el concepto de componentes de servidor, esto todavía estaba en Meta, no se había anunciado afuera, fue hecho muy específicamente para el newsfeed en Facebook, porque hay, no sé, 26, 38, olvidé el conteo, pero un gran número de posibles tipos de publicaciones que un newsfeed puede tener, y casi todos son bastante estáticos, con algunos bits interactivos, y fue una optimización para no enviar todos estos diferentes componentes que podrías o no necesitar, y si pudieras simplemente ejecutarlo en el servidor. Y así, esa optimización fue el objetivo original, pero ha evolucionado en algo más para cuando realmente se lanzó, donde es más una arquitectura, es más una cosa de obtención de datos, y creo que debido a toda la evolución y en lo que se ha convertido, como, no hay una parte definida de lo que son los componentes de servidor, así que cuando tenemos discusiones al respecto, la gente está hablando de cosas diferentes.

Para algunas personas es solo un formato de serialización que se puede usar solo para devolver datos de un cargador, y para otras personas es toda una arquitectura donde tienes como mutaciones y cosas así, y no creo que podamos tener una conversación productiva hasta que resolvamos ese debate de qué son los componentes de servidor, cuál es la arquitectura de NextJS, y dónde está la línea. Sí, eso tiene sentido. Antes de pasar de este tema, quiero hacer una rápida encuesta a la audiencia, así que levanten la mano si habían oído hablar de los componentes de servidor antes de hoy. Bien. Ese ha sido el framework. Casi todos. Este tipo aquí no había oído hablar de los componentes de servidor antes de hoy. ¿Qué hay de las personas que los han usado o probado, digamos? Sí, está bien. ¿30%? ¿30% tal vez? Sí. Entonces, ¿quién los usó en producción en un producto real? Como 15 personas, 10 personas, ¿sí? Así que está bien, creo que eso es representativo del ecosistema en su conjunto. Tienen una gran cuota mental, pero el uso práctico todavía es un poco lento. Bien. Bien, así que pasemos de esto, y una pregunta que la gente sugirió fue sobre qué características de React son tal vez infrautilizadas, o quieres resaltar algo que la gente tal vez ya esté usando, pero hay algún aspecto oculto donde puedes darnos pequeños consejos tal vez? Iré con uno, que creo que la mejor adición a React en mucho tiempo es la función use. No es un hook, así que no sé si está bien nombrado, pero es muy flexible, puedes usar en diferentes lugares. Ahora mismo es solo para promesas y contexto, pero lo que más espero es cuando se pueda usar para más tipos de datos, que es algo de lo que el equipo de React ha hablado. Sí, lo siento, adelante.

Voy a decir el compilador. Creo que está muy subestimado, y aunque estamos teniendo nuestros propios pequeños dolores de crecimiento con él, con las bibliotecas TanSac, es bastante impresionante lo que puede hacer. Especialmente solo para el código de usuario, y tengo mucha curiosidad por ver hacia dónde va a ir. No sé por qué, solo tengo la sensación de que es solo el comienzo de un largo viaje hacia un rendimiento mucho mejor y tal vez incluso flexibilidad de cómo usamos React en el futuro. Creo que es un área realmente candente donde podemos usarlo hoy. Creo que está en candidato a lanzamiento, y es bastante bueno, y sin embargo también están iterando rápidamente en él y aprendiendo un montón de cosas nuevas y geniales mientras lo construyen. Para mí, casi, y siendo muy orientado al lado del cliente también, es directamente aplicable a las cosas que construyo, y es como si viera al equipo de React, supongo que me ven cuando están construyendo el compilador, y me gusta ser visto. Por eso estoy emocionado por ello.

De hecho, tengo curiosidad, hacemos las mismas encuestas para el compilador. ¿Cuántos de ustedes han oído hablar del compilador antes de hoy? Bien, un buen número. ¿Cuántos de ustedes al menos lo han probado en una aplicación de juguete? Relativamente pocos. ¿Cuántos de ustedes están ejecutando el compilador en producción? Como, adiós. Bien, lo tengo. El objetivo del compilador es tanto mejorar el rendimiento de la re-renderización, como, bueno, pensé, una de las cosas que la gente siempre ha malentendido sobre React es la forma en que funciona el modelo de renderizado, y por eso escribí un blog de 12,000 palabras sobre el tema. Los componentes no se re-renderizan si cambian las props. Los componentes se re-renderizan cada vez que lo hace el padre, lo que significa que si configuras, digamos, aquí, simplemente se propaga automáticamente a través de todos los hijos.

El compilador realmente le da la vuelta a eso, y si tienes el compilador activo en una base de código, por primera vez, realmente es tu componente solo se re-renderiza si los datos de las props realmente cambiaron. Esto comienza a plantear algunas preguntas. Si llegamos a un mundo donde asumimos que el compilador está activado por defecto en la mayoría de las bases de código, ¿cómo enseñamos realmente cosas como el proceso de renderizado? Porque está el comportamiento por defecto, pero luego está la forma en que el compilador modifica ese comportamiento. Gran pregunta. Probablemente vamos a necesitar labores donde sea estricto, y si el compilador—ahora mismo, falla de manera elegante, pero probablemente debería afirmar que el lenguaje—porque siento esto también, como a veces en lugar de un use effect o algo, simplemente tendré alguna animación de nivel superior que comienza, lo cual es una práctica totalmente mala, pero funciona en el compilador, pero luego puedes ejecutar algún código no relacionado en el compilador que luego rompe la optimización, y luego cambia el—se propaga y tiene todos estos efectos secundarios, así que en casos como ese, preferiría simplemente hacer cumplir que está activado, o recibir un error, pero es una estrategia de migración. Tengo mucha fe en que el equipo de React agregaría más opciones estrictas.

Sí. Creo que, sí, ahora mismo lo implementamos de manera muy laxa para que podamos intentar que más personas lo habiliten, pero en algún momento eso tendrá que cambiar y tendrá que ser estricto por defecto. Porque el último modo estricto fue genial. Sí, sí, cada modo estricto siempre ha funcionado. Perfectamente. Sí. Quiero decir, lo que mucha gente no se da cuenta es que el compilador ya puede estar por defecto activado o desactivado, y puedes activarlo o desactivarlo para un componente, para un hook, y así que realmente no creo que haya ninguna razón para que alguien no comience a usarlo. Creo que el 100% de los desarrolladores deberían estar usando el compilador hoy, y puedes simplemente no activarlo globalmente y solo activarlo para un componente, y si no se rompe, simplemente sigue activándolo en más componentes y obtienes mágicamente algo más rápido sin trabajo.

¿Dónde podría la gente ir para aprender más sobre cómo hacer eso? Así que la documentación del compilador de React no menciona las opciones, por lo que tienes que buscar para ver cómo activarlo en el paquete npm, pero está ahí. Si lo buscas, lo encontrarás. Lo siento, tenía que hacerlo. Así que pasando de las características que queríamos resaltar a ahora características que faltan en React, o tal vez características próximas que podríamos querer buscar. ¿Nuevas características que vienen a React? Ya sea nuevas características que realmente están llegando o características de la lista de deseos que desearías que llegaran. Oh, lista de deseos de características. Oh, hombre. Sí, solo un constructor de IA integrado, como, por defecto. Como, puedes agregar un token o algo.

No sé. Una cosa que me gusta de React es que con el tiempo, solía ser realmente pesado, y había, como, antes de JSX, era como React.create, y luego JSX salió muy rápidamente, y luego tenías, como, React.create class, y luego eso como que desapareció en términos de clases y funciones, y simplemente comenzó a, como, desaparecer más y más, y luego se siente más como que React es como el lenguaje alrededor de JavaScript. Se siente más puro al JavaScript de alguna manera, aunque es un poco, y el compilador también hace esto. Si miras, como, donde todavía ves React en un componente, tienes, como, use memo, use callback, use effect, use state, y así, como, si usas componentes del servidor, entonces puedes deshacerte de muchos use effect y use states.

Si usas el compilador, puedes deshacerte de muchos use memo y use callback para desaparecer. Y así, como, cuando estabas usando componentes del servidor y el compilador y luego miras los resultados, como, ¿dónde todavía ves el React donde tienes que salir un poco del JavaScript y hacer algo que se siente menos natural? Porque, como, async de alguna manera se siente mucho más natural que use effect y use state. ¿Sabes lo que me gustaría ver? Límite de error integrado. Por favor. Ya es hora. Entonces podemos deshacernos de los componentes de clase para siempre. Sí. Quiero decir, solo repetiré la función use nuevamente. Estoy, como, esperando que la función use soporte, como, señales e iterables asíncronos o, como, una tienda externa de sincronización de uso fija. Creo que ese gancho roto es probablemente el mayor defecto en React hoy porque cada biblioteca del ecosistema para datos lo usa. Y ninguno de ellos es, como, seguro para el aprendizaje concurrente.

Hay dos cosas que quiero que React soporte. Una es la obtención de datos sin una biblioteca externa. No quiero ir a nadie más. Solo quiero obtener mis datos en React sin que nadie me grite que no use use effect. Y segundo, quiero gestionar mi estado en React sin algo además de use state. Algo que no me haga saltar hacia Redux o Zojtan. Así que quiero que React pueda encargarse de la obtención de datos y la gestión del estado para que no tenga que ir por las bibliotecas. Sé que me van a odiar porque es, como, su trabajo. Pero quiero que React pueda soportarse completamente a sí mismo hasta que haya un caso de uso realmente bueno para que no lo haga. Creo que eso vuelve al debate de marco versus biblioteca donde deberías tener un enfoque todo en uno o mantenerte en tu carril y hacer algo muy específico.

No creo que alguna vez resolvamos ese problema porque son solo dos filosofías diferentes. Sé que el equipo de React ha dicho que al menos están explorando la idea de algún tipo de objeto de tienda integrado que no estaría vinculado a un componente específico. Creo que eso todavía es solo, como, exploraciones muy tempranas. Algo que está relacionado pero un poco diferente que tal vez esté más avanzado. Así que ahora mismo, bibliotecas externas como Redux, etc., dependen de un gancho llamado use-sync-external-store que suscribe algo como la tienda Redux. Y cuando la tienda se actualiza, desencadena un rerender de React y esa es la forma aprobada oficialmente para que las bibliotecas externas se conecten a React. Pero tiene una limitación que es si estás haciendo renderizado concurrente con ya sea una transición de uso o suspense o algo más, si hay una actualización de la tienda mientras React está como pausado en el medio, entonces en realidad tiene que desechar el trabajo en progreso y comenzar de nuevo y hacer un renderizado de estilo antiguo de principio a fin que podría tomar algo de tiempo. Así que esa es solo una limitación inherente porque el punto del renderizado concurrente es que React posee el estado y puede decir, comienza a aplicar esto, ups, no, déjalo a un lado, haz otra cosa, vuelve, reaplica, termina. Y si el estado es externo, React no lo posee.

No puede reordenar cosas. El equipo de React presentó recientemente un PR para algo que están llamando, como, una tienda compatible con la concurrencia. Todo lo que tenemos ahora es, como, un párrafo en la publicación de blog más reciente de labs y luego un borrador de PR con las pruebas. Así que ni siquiera sabemos cómo se ve en la práctica todavía. Pero si estoy leyendo esto correctamente, parece que se supone que es un reemplazo para use sync external store que nos permitiría ser compatibles con la concurrencia de alguna manera. Espero. Tal vez. Por favor. Lo usaría lo antes posible.

Sí. Así que, sí. Vi estos PRs y tuve, como, la impresión de que era más como un Zustand de primera mano y no un reemplazo para use sync external store todavía. Pero podría estar equivocado. ¿Quién sabe? Lo descubriremos. Estaría feliz con un Zustand de primera mano integrado en React. Sí. Así que creo que le pido esto a Joe Savona una vez al mes. Digo, dame use external store, y él dice, ¿por qué? Y yo simplemente bajo la cabeza y me alejo. Pero realmente sería bastante increíble obtener ese gancho o, ya sabes, esa utilidad de React.

Al menos ahora mismo en muchas de las bibliotecas que tenemos en Tanstack, tenemos que tomar decisiones sobre si queremos soportar un re-renderizado muy fino y selectores, que es generalmente donde nos quedamos, porque queremos el mejor rendimiento que podamos obtener. Pero no podemos tener soporte completo de transición y concurrencia con eso. Así que eso es una bifurcación en el camino para nosotros. Y algo como use external store, donde podríamos permitir que React versionara nuestro estado externo según lo necesite, fundamentalmente nos permitiría tener ambos de esos. Y eso sería un gran cambio de juego.

Volviendo a tu charla, uno de los temas fue este problema de cómo comunicar nuevas características, cómo interactuar con la comunidad. Y creo que es un desafío para cualquier proyecto. Especialmente uno del tamaño e influencia de React. Así que me pregunto si tienen alguna idea de cómo podría mejorarse eso. ¿Hay algo que el equipo de React podría hacer de manera diferente? ¿Hay algo que tal vez la comunidad debería abordar de manera diferente?

¿Cuántas horas tenemos? Tengo una lista de ideas, pero para mantener un par de ellas. Una que desearía, que probablemente no suceda, sería, como, un roadmap público constantemente actualizado. Ahora mismo, la mayoría de nosotros simplemente tenemos que ver el repositorio de React para un PR temprano, y luego la gente se emociona porque esta nueva característica está llegando y luego tal vez nunca se lanza o itera durante mucho tiempo. Idealmente, lo que me gustaría ver sería algo parecido a las etapas TC39 para características de JavaScript, donde podrían decir, esto es etapa uno, ni siquiera estamos comprometidos con ello, probablemente va a cambiar, no es final, pero para que lo sepan, estamos trabajando en ello. Solo para que tengamos alguna idea como comunidad de hacia dónde creen que se dirigen.

En términos de comunicación, cuando React 18 salió, hubo un grupo de trabajo público donde incluyeron a muchas personas de la comunidad. Hubo un foro de discusión público donde podíamos hacer preguntas, podíamos enviar preguntas que veíamos externamente, y luego el equipo de React realmente leía esas y respondía y hubo algunas buenas explicaciones y discusiones. Todavía creo que fue una de las mejores interacciones que el equipo de React ha tenido con la comunidad. Me encantaría tener como un grupo de trabajo permanente en el futuro, como cuando React App se rompió, después del lanzamiento de React 19, me quejé mucho en Blue Sky porque realmente no tenía otra forma de, sentía que podía comunicarme, y eventualmente eso se solucionó. Pero habría sido más fácil si hubiera habido como un foro de discusión designado donde podría haber dicho, oye, esto está roto, para que lo sepan, y habría sabido que iban a mirarlo y responder.

Sí, yo apoyo el grupo de trabajo. Creo que como educador, fue una gran manera de hacer todas las preguntas pero también de empezar a construir recursos para la comunidad antes de que el lanzamiento saliera. Así que había mucho más para leer y aprender fuera de lo que los documentos de React 18 decían. Uno de los mejores hilos que todavía recuerdo de ellos, de esa discusión en GitHub fue "explícalo como si tuviera cinco años" y eran como un montón de conceptos diferentes. Todavía está en vivo, todavía está ahí. Creo que fue una iniciativa increíble crear un grupo de trabajo, y lo que me encantaría ver es que ese grupo de trabajo continúe para cada lanzamiento futuro, pero también que haya un lugar donde la comunidad pueda ir y hacer preguntas a los mantenedores principales, especialmente para nuevos lanzamientos como el compilador. Tengo cientos de preguntas. ¿Dónde pregunto esto?

Bien, sí, creo que es una gran idea, como un grupo de trabajo y también ese sistema de etapas. Es definitivamente útil, ya sabes, como alguien que también sigue JavaScript y CSS y muchos otros lenguajes y tecnologías, saber si una característica es, como dijiste, una idea temprana que podría desaparecer o realmente algo que se va a implementar en los navegadores inminentemente, eso es súper valioso, porque de lo contrario puede ser realmente difícil distinguir entre esos. Así que creo que todavía tenemos un poco de tiempo. ¿Hay algún otro tema que quieran mencionar? ¿Errores comunes? Errores comunes, sí. También discutimos esto anteriormente. ¿Hay errores comunes en React, errores comunes que la gente comete, tal vez principiantes, especialmente cosas que deberían evitarse? Creo que empezaré con uno.

Así que habiendo revisado muchos PRs en Slack y Paypal, muchas veces no gestionamos nuestras dependencias correctamente, y eso puede llevar a muchos renderizados. Así que use memo, use callback, use effects, los tres hooks comunes que aceptan dependencias que mucha gente usa en el código. Hay herramientas de linter que pueden realmente resaltar que te falta una dependencia. Así que el paso número uno, instala una herramienta de linter que pueda ayudarte a resaltar eso. Número dos, aunque el linter resaltará que la dependencia está añadida, todavía es tu trabajo averiguar que la dependencia es granular en sí misma, para que no estés añadiendo un objeto enorme si no estás usando el objeto. Y el problema con eso es que cada vez que la dependencia cambia, se volverá a renderizar y tu componente se volverá a renderizar, hay implicaciones de rendimiento.

Así que el mayor error que destacaría es gestionar las dependencias de manera granular. Y solo para aclarar, te refieres a los arrays de dependencias para use effect y demás, no como las importaciones? Sí, sí, array de dependencias, gracias. En eso, yo diría que usen el compilador, dejen de usar use memo y use callback, y para use effect, no intenten escribir las dependencias ustedes mismos. Solo dejen que la regla de lint las escriba. Esa es la única manera correcta. Cualquier otra manera está mal. El compilador también te advertirá y dejará de funcionar si no escribes las dependencias exactas que la regla de lint escribe. Creo que el único lugar donde tienes que tomar una decisión es si estás leyendo una clave de un objeto, así que como objeto.a, la regla de lint podría sugerir el objeto en sí y puedes poner objeto.a, que es un poco más granular, y eso suele ser mejor. Eso es todo. Aparte de eso, no intentes gestionar las dependencias tú mismo.

Estoy de acuerdo en que ese es el error más común que veo. Las cosas se rompen de maneras muy extrañas y sutiles cuando las dependencias están mal y no hay una manera fácil de arreglarlo porque empiezas a depender de ese comportamiento con el tiempo y luego nunca puedes arreglarlo. Quiero decir, vi antes las estadísticas sobre la gente, como hay un gran porcentaje de personas que no usan frameworks, así que solo asegúrate de que estás usando las reglas del plugin de React yes lint y tienes las reglas de hooks habilitadas, porque esa es básicamente la interfaz pública para que React se comunique contigo, como los problemas obvios en tu proyecto. Y luego no, si estás en React 19, saca todos los forward refs, es terapéutico.

Otro tipo de error sutil que veo son los componentes extra grandes. Está bien dividir los componentes. Suele ser mejor para el rendimiento. No hagas mega componentes. Con la nueva API de uso, he estado haciendo mis componentes extra grandes solo para tener lugares donde usar llamadas condicionales. Esa es la cosa, por eso creo que es un error. Es muy fácil hacer componentes grandes y luego cuanto más grandes se hacen, peor es el rendimiento y más probable es que tengas alguna violación de las reglas de React y el compilador dejará de funcionar. Pero si tienes muchos componentes pequeños, incluso si uno o dos no funcionan, si el resto de ellos están memorizados, obtienes los beneficios de rendimiento. Es genial. Sí. Sí, la gente definitivamente debería revisar la API de uso y todo el nuevo contexto de React, porque funciona, aunque se siente ligeramente diferente, los efectos son profundamente diferentes.

Solo puedo imaginar a alguien aprendiendo sobre React desde la versión 19 en adelante y tal vez no recurriendo a una biblioteca diferente de gestión de estado. Porque, oh sí, solo crea un contexto, súper simple. Incluso eliminar el dot provider hace que se sienta un poco más cercano a una biblioteca moderna de gestión de estado, y luego poder llamarlo condicionalmente, hacer selectores de contexto casi se siente fantástico. Así que, un mundo completamente nuevo, incluso con solo pequeños cambios en la API. Sí.

¿Algo más? Bueno, ya sabes, creo que ya cubrimos mucho terreno, así que este podría ser un buen lugar para detenernos. Alguien definitivamente debería escribir un post en un blog para resumir todo lo que dijimos. Estoy mirando en tu dirección. Puedes añadirlo a la lista, sé que has... Has sido nominado. No tengo suficiente tiempo para escribir todo lo que quiero escribir de todos modos.

Y una cosa que debemos recordar es que las personas aquí no solo son grandes panelistas, sino que ustedes realmente hacen las herramientas que todos usamos. Así que creo que todos merecen un gran aplauso. Y gracias por hoy, y también no olviden la encuesta del estado de React que saldrá en algún momento, probablemente en septiembre. Así que estén atentos a eso. Gracias a todos. Gracias, Satchel.