Manejo de datos a gran escala para desarrolladores de React

De todos modos, ¡hola! ¡Encantado de verte! Soy Tajus, solía decirles a las personas. Solía decirles que era como algo, pero ahora digo que es como ventajoso. De todos modos, soy el director de relaciones con desarrolladores en Zara. Mira esta cosa hermosa. Esa es mi diapositiva favorita y también una de mis cinco diapositivas. Vamos a escribir mucho código en esta charla y aprender correctamente. Por cierto, esto fue hecho por Sarah Vieira, ella está aquí, ella está haciendo la última charla hoy, así que si quieres aprender cómo hacer cosas en 3D, no te la pierdas. Pero eso no es de lo que estamos aquí para hablar hoy.

Estamos aquí para hablar sobre cómo manejar data a gran escala para desarrolladores de react. Manejo de data a gran escala para desarrolladores de react. ¿Qué significa eso? Esto suena como una charla de marketing muy abstracta y la respuesta es porque no es una charla de marketing, pero es abstracta a propósito para que pueda cambiarla en el último minuto como siempre hago, ¿de acuerdo? Pero seamos más específicos y veamos un diagrama de lo que queremos decir con data a gran escala. Para hacer eso, vamos a usar una herramienta increíble llamada Excalidraw. ¿Cuántos de ustedes han oído hablar de Excalidraw? Sí, si quieren aplaudir a Excalidraw, sí, por supuesto. Data a gran escala. Esto es lo que parece. Por lo general, tienes una aplicación de React o una interfaz de usuario de React, digamos, ¿verdad? ¿El texto está bien? ¿Todos pueden ver? Bien. Lo sabía. Acabo de preguntar y lo que vamos a hacer es que por lo general tienes una interfaz de usuario de React que se comunica con una API que, vamos a alejarnos un poco, que luego se comunica con una database y estas conexiones generalmente se ven un poco así. Así que esto puede ser demasiado simplificado, pero eso es lo que la mayoría de las aplicaciones hacen. ¿Esto es a gran escala? Probablemente no. Esta es una única database de host y así sucesivamente. En algún momento, experimentarás un crecimiento y el rendimiento se vuelve importante. Entonces, ¿qué haces? Probablemente distribuirás tu API. Tener un único punto de falla generalmente no es recomendable, así que lo que harás es eso y tendrás múltiples APIs que pueden obtener datos múltiples veces y lo que sea. Y puedes balancear la carga entre ellos. Y luego, bueno, vas a ser como, esto está genial, pero si creces, ¿qué hacen las cosas exitosas? Crecen. Entonces, si creces, vas a estar como, oh no, nuestra database ahora es el cuello de botella. Vamos a escalarlo.

Entonces escalarás verticalmente. Y esta escala vertical generalmente significa agregar memoria, agregar espacio en disco, agregar cosas. Y se vuelve bastante costoso. Eventualmente construyes una supercomputadora. O, si quieres escalar tu base de datos de la otra manera, escalarás horizontalmente, lo que significa que tendrás una instancia principal y algunas réplicas. Entonces, cuando obtienes datos, se distribuyen en las réplicas y así sucesivamente.

Pero luego crecerás más. Y estamos hablando de datos a gran escala, por lo que es importante establecer este contexto. Crecerás un poco más. En algún momento, te darás cuenta de que nuestra base de datos sigue siendo lenta para leer. Y eso se debe a que generalmente las bases de datos leen desde el disco. El disco, por diseño, no es tan rápido como qué cosa. Memoria. Memoria. Así que, ahora, he tenido esta conversación al menos 50 veces en la última semana. Eso es una mentira porque soy un orador público. Realmente no lo he hecho. Pero ya sabes cómo es.

Entonces, agregarás algún tipo de base de datos en memoria solo para leer más rápido. Esto probablemente también estará distribuido. Y ahora tu aplicación hablará con esa cosa para obtener datos rápidos. Y si no está en caché, entonces lees desde la base de datos. ¿De acuerdo? Esto es cercano a cómo se ven las cosas a gran escala. Creo que el sitio web de Kent C. Dodd tiene algo así en la parte posterior. Pero a medida que acumulas volumen de datos, ¿cuál es la característica común en cosas con toneladas de volumen de datos? Búsqueda. Entonces, GitHub, TikTok, Instagram. Eventualmente, cuando tengas suficientes datos, necesitarás búsqueda. Y ahora se vuelve complicado, ¿verdad? Porque tu aplicación puede leer desde el motor de búsqueda, pero estará vacío. Solo estás como... De acuerdo.

No hay nada allí. Tendrás que encontrar una forma de replicar los datos de tu base de datos en tu motor de búsqueda, probablemente en tiempo real con algún tipo de consistencia. Las personas usarán una herramienta como Kafka o algo similar. Y enviarás tus datos allí, y esto replicará tus datos en la búsqueda. Y ahora todo está conectado. ¿De acuerdo? Si quieres tomar una foto de eso, es una buena representación de cómo se ve la infraestructura de datos en la mayoría de los casos a gran escala.

¿Es eso de lo que vamos a hablar en esta charla en React Summit? Esto es lo que quiero establecer con este diagrama. Por el bien de esta charla, vamos a hacer que todo lo que está con una línea discontinua sea problema de otra persona. Esto se trata de React. Se trata de manejar datos a gran escala en React. ¿De acuerdo? Es muy importante que te lo diga.

Ahora, quiero hablar contigo sobre cómo manejar datos a gran escala en React, específicamente sobre la obtención de datos. ¿Y cómo podemos hacer esto? Ahora, hay algo que se puede decir sobre el renderizado del lado del cliente, el renderizado del lado del servidor, y así sucesivamente. Lo que quiero hablar hoy son tres formas de obtener datos en React. Esto se ha hablado varias veces. No es algo nuevo. Pero antes de hacerlo, necesito aclarar. Esta charla se trata de lo que he aprendido y de lo que puede ser útil para ti. Creo que te será útil. Pero generalmente quieres confiar en bibliotecas que estén probadas en batalla, incluso con pruebas unitarias, que manejen casos extremos que no podemos prever. ¿Está claro? El propósito de esta charla no es que debas hacerlo de esta manera, usarlo en producción. Es más bien, quiero enseñarte cómo funcionan las cosas para que lo entiendas. Así que nos vamos con algo que sabemos. Con eso, hay tres formas de obtener datos en React. Estas son las tres formas predominantes. La número uno, probablemente la más común, es renderizar tu componente y luego obtener los datos. Tienes un componente, useEffect, fetch, .then, setState. Esto es bastante común. ¿Cuántos de ustedes lo hacen? ¿Lo han hecho al menos una vez? Sí, está bien, toda la sala.

La siguiente forma es fetch, luego renderizar. Y esto se ve en algunas bibliotecas, como NextJS, donde exportas get server side props. Obtendrás los datos en el servidor y luego renderizarás tu componente. Hay algo que se puede decir al respecto. Es posiblemente más rápido. ¿Por qué? Porque comienzas tu fetch antes, antes de que comience el renderizado de tu componente. Y luego, tan pronto como esa promesa se resuelva, la estableces en el estado, y listo.

La tercera forma es renderizar mientras obtienes los datos. Esto es posible gracias a las nuevas características concurrentes en React 18, y pasaremos la mayor parte de nuestro tiempo escribiendo código de esa manera específica para entenderlo. Pero como dije, el equipo de React es muy claro, no hagas esto de forma ad hoc, sino usa una biblioteca. Es lo mejor. Dicho esto, hagámoslo ahora, solo una vez. Así que con eso, esa es mi última diapositiva. Vamos a codificar. Me gusta codificar. Inshallah, el internet funciona.

De acuerdo, así que vimos el diagrama. Lo que quiero mostrarte es una aplicación. Tendremos una aplicación que obtiene datos de estas tres formas. La aplicación, déjame iniciar mi servidor de desarrollo aquí. La aplicación, estamos usando Parcel, solo porque para mí es realmente genial para las demostraciones. Oops, src slash, lo siento, es yarn parcel, src slash index dot html. Esto va a abrir nuestra aplicación. Y lo que tenemos es una aplicación de chistes. Estos son chistes para desarrolladores, clásicos. Curados por la única y maravillosa Shruti Kapoor, por cierto, un saludo. Ella es un miembro muy valioso de la comunidad y del equipo. Y si no la sigues, deberías hacerlo. La razón por la que está en esto es porque ella cura una colección de chistes para desarrolladores. Por ejemplo, ¿cómo consuelas a un desarrollador de JavaScript? Los consuelas.

De acuerdo, así que lo acabo de robar de aquí. Lo que vamos a hacer rápidamente es obtener datos de tres formas. Primero lo haremos de la forma que todos conocemos, así que nuestra aplicación. Tenemos una aplicación de React que utiliza Create Root, es algo nuevo. Tenemos nuestro componente de aplicación que renderiza, como puedes ver, los elementos reales aquí, el encabezado, los chistes, y así sucesivamente. Y por último, tenemos un componente de chistes, esta cosa, que debería obtener datos pero no lo hace. Así que obtendremos datos de tres formas y luego hablaremos de lo que aprendemos.

Para hacer eso, voy a obtener mis datos de aquí y obtenerlos inmediatamente. Nuevamente, inshallah, red, por favor. Genial, eso es suficiente. ¿Sabes qué pienso? Creo que la red depende de... Bueno, no importa. Iba a hacer algo increíble, pero ahora no lo haces.

De acuerdo, voy a obtener un fragmento de código aquí en JavaScript para obtener esto en mi aplicación, solo del lado del cliente, como sabes. Así que haremos algo como esto. Y cuando cambie la búsqueda, simplemente obtendremos de nuevo. Pegaremos el fragmento de código. Agregaré un filtro, solo por diversión, donde el chiste contiene la búsqueda. Y luego, en lugar de imprimir el resultado en la consola, estableceré el chiste en los registros de resultado, ¿de acuerdo? Solo estoy obteniendo datos. Estás familiarizado con esto. No estoy dedicando demasiado tiempo a esto. Y así, tenemos chistes de una API. ¿Cuál es el lenguaje más utilizado en la programación? Palabrotas. Ja ja, en realidad es gracioso. ¿Funciona la búsqueda? Puedo usar palabras como okay feenot. Pero bueno, casado, vida de desarrollador, esposa, ¿verdad, 100%? Así que estamos obteniendo, estamos renderizando el componente, luego obteniendo. Esto es bastante común. Si revisamos el código brevemente, tenemos los chistes en el estado, obtenemos y establecemos el estado, y luego todos están felices. Observa que aún no estamos manejando los estados de carga.

Llegaremos a eso. Esta es la forma tradicional. ¿Qué tal obtener y luego renderizar? Esto se ve menos común en Userland. He hablado con algunos de ustedes y están como, ¿qué es eso? Básicamente, la idea principal es comenzar a obtener temprano, para que tu tiempo de carga se reduzca. Y esto ayuda si estás cargando un componente con React.lazy y lo estás importando dinámicamente, luego, tan pronto como se importa el componente, se obtiene inmediatamente y luego se renderiza. Esto es realmente rápido. Y en nuestro caso aquí, tenemos 20 minutos, así que vamos a trabajar con un salto de red, pero en casos en los que tienes varios, esto realmente te ayuda a evitar las cascadas de red, es decir, tienes una solicitud, esperas, tienes otra solicitud, esperas, y así sucesivamente.

Esto es renderizar y luego obtener. Hagamos obtener y luego renderizar. Entonces lo que vamos a hacer es sacar todo este fragmento de código de useEffect y ponerlo aquí en el ámbito del módulo. Y estás como, ¿cómo puede ser esto? No tienes setJokes. Exactamente. Así que voy a tomar esta parte, ponerla de nuevo en useEffect y hacer promise.then setState. ¿Qué es promise? Es mi llamada fetch desde el ámbito del módulo. ¿Esto se ve extraño? Tal vez, porque no has visto esto tanto. Así que no obtenemos la dinamicidad, lo que sea, la dinamicidad de la propiedad de búsqueda aquí. Debido a que estamos obteniendo en el ámbito del módulo, ¿funciona? Sí, y es posiblemente más rápido. ¿Por qué posiblemente más rápido? Porque estamos obteniendo antes de renderizar. Entonces los datos están listos. El problema con esto, por supuesto, es que simplemente estará obsoleto. No puedo controlarlo con props. Tal vez si hiciera promise como una función, como obtenerPromise o algo así. Claro. Pero no es tan común, especialmente si estás fuera de una biblioteca y los beneficios de rendimiento son, no sé, cuestionables.

Hablemos de renderizar a medida que obtienes. ¿De acuerdo? React 18 tiene características concurrentes donde puedes comenzar a renderizar un componente y cuando llegas a un componente que aún no está listo, que aún no tiene datos, React no lo renderiza. Lo renderiza como un hueco, un fallback, y luego continúa por el árbol. Y luego, cuando el componente está listo, luego lo renderiza. Entonces es como, renderiza tanto como puedas, obtén mientras lo necesites, y luego vuelve a renderizar.

Esto es lo que vamos a ver. La herramienta que permite esto se llama Suspense para la obtención de datos. Hay un RFC al respecto aquí. Confía en el RFC, no en mí. Esta charla solo condensa esto con ejemplos, pero esta es la fuente de verdad, al igual que el blog de React y la documentación de React.

Específicamente, quería mostrarte Suspense y los marcos de datos. Esto es importante. Aprende cómo funciona, o tal vez no lo hagas tú mismo. Esto es solo para comprender.

Ahora, ¿cómo funciona este Suspense para la obtención de datos? Veamos un ejemplo aquí. Ya estamos obteniendo en el ámbito del módulo. Lo que quiero hacer es crear algo llamado un recurso. Es como una primitiva que Suspense para la obtención de datos utilizará, y así es como se ven. Tendré una función llamada createResource. Envolveré todo mi componente en ella. ¿De acuerdo? Necesitaré dos estados. Necesitaré el resultado, que puede ser cualquier cosa. Esto es TypeScript. Y necesitaré el estado, que al principio es inicial. Tengo un montón de plantilla aquí. No voy a tocar eso. Lo que puedo hacer es promise. En realidad, solo agregaré un punto aquí, y ahora tengo datos. Entonces, datos, y estableceré mi estado. El resultado es datos.registros, el estado es hecho. Haré lo mismo para catch. Entonces, .catch. El estado es error, y el resultado es, en este caso, ni siquiera son datos. Permíteme corregir eso. Bien, cuando la promesa se resuelve, actualizaremos nuestro estado del ámbito en esta función.

¿Qué hace esta función createResourceReturn? Devuelve... Realmente puede devolver lo que quieras. Pero en este caso, estamos devolviendo un objeto con una función llamada read. Y lo que hará read es si el estado mantenido en esta función es inicial... También puedo usar un switch case para esto. No lo estoy haciendo solo porque no quiero. Si el estado es inicial, significa que los data aún no se han cargado. Esto fue controvertido, así que lanzo la promesa aún no resuelta. ¿Quién la va a capturar? React. Y luego, cuando esté listo, React continuará renderizando. Si el estado es error, lanzaremos el resultado en su lugar. Y si el estado es hecho, ¿escribí hecho? Si el estado es hecho, simplemente devuelvo el resultado. Devuelvo el resultado. Y así React sabe cómo manejar esto. Esto es lo que manejan. ¿De acuerdo? Lo que voy a hacer ahora, después de guardar con Prettier, es crear un recurso inicial.

Y lo crearé así. ¿De acuerdo? Y en lugar de todo este código de setState, en lugar de todas estas bromas aquí, simplemente voy a leer desde mi recurso inicial de esta manera. Guardar. Volvamos a la demo. Y funciona. Entonces, ¿cuál es el beneficio de esto? Esto es genial. Hay algunos beneficios.

Por ejemplo, no reemplaza... Bueno, en realidad no busca. Necesitamos resolver eso primero. ¿Verdad? Pero mira el estado de carga. Es instantáneo. No hay, como, destello. Además, si limitamos la solicitud de red, solo para hacer... Este backend es demasiado rápido. Ni siquiera sé qué es. Pero limitemos esto en su lugar, si puedo... Sí. Entonces limitemos esto aquí. Y ahora... Limitemos esto mucho. Hagamos, como, tres segundos. Y ahora lo que notaremos es que no tenemos nada durante tres segundos. Y toda la aplicación aparece cuando se cargan las bromas. Esto no es ideal user experience.

Entonces, en su lugar, lo que podemos hacer es ir a nuestra aplicación contenedora y envolver solo la parte que necesita data en el componente suspense de React. Y ahora, si cargamos la página... Espera, espera, espera, espera, espera. Tres segundos. Boom.

Pero con suspense, en realidad podemos elegir diferentes partes del DOM para ocultar. Así que lo movimos, ahora ocultamos el párrafo. También podemos ocultar el campo de entrada para que no escribas y luego se cargue. Eso es suspense. Por cierto, esto también funciona en el lado del servidor, de forma predeterminada. Sin cambios de código. No debes implementarlo tú mismo, confía en la biblioteca, pero suspense en el lado del servidor funciona exactamente así. El HTML se pausa mientras se descarga.

Lo último que quiero mostrarte es cómo hacer que esto funcione, en realidad, hagamos que la búsqueda funcione. Así que ya estamos aquí. Lo que necesitamos hacer es utilizar un efecto para que cuando cambie la búsqueda, recreemos el recurso. Así que haremos 'resource', o simplemente 'R', y 'setR'. Y usaremos el estado 'initial resource'. Eso es esto. Y ahora usaremos esto en su lugar. Así que cuando cambie la búsqueda, estableceremos 'R' con la búsqueda como parámetro. Y nuestro recurso creado aceptará una búsqueda, que es una cadena. Y aquí reemplazaremos 'search' con 'search'. Así, tal cual.

Esto se ve genial. 'setR' necesita un recurso, así que creamos un recurso aquí. Y ahora, cada vez que cambie la búsqueda, el recurso que obtiene los data cambia y nuestra búsqueda debería funcionar, pero podría ser que mi, sí, mi token de acceso haya expirado. Necesito uno nuevo. Los últimos 10 minutos para que no puedas husmearlos y robarlos, así que volvamos a mi llamada fetch aquí y reemplacemos esta cosa. De acuerdo, genial. Y ahora, oh.

Estoy haciendo algo mal, ¿verdad? Inshallah la red no está funcionando de nuevo. De acuerdo, es 400. Correcto. Lo siento, me refería a que la broma contiene búsqueda. Oh, gracias. A quien dijo eso, te aprecio. Ahí tienes, prop predeterminado y ahora debería estar en lo correcto. De acuerdo, ahí vamos, pero hay un destello. Mira, así que ahora si intento buscar esto, si escribo como W, ah. ¡Hey! Entonces, ¿qué pasa con, qué pasa con I? Ocultas mi, ah. Así que mira, una pulsación de tecla es una actualización urgente. Cambiar los resultados no es una actualización urgente. Necesitamos una forma de decirle a React qué actualización es urgente y qué puede esperar un poco. De acuerdo, para hacer eso, usamos otra característica concurrente llamada useTransition. Esto es un gancho y es realmente importante, así que presta atención. Entonces obtienes un par de carga y transición de inicio de este gancho, useTransition. Lo que haremos es envolver este set state del recurso en esto. Y así, React ahora sabe, voy a esperar todas las cosas urgentes y luego efectuaré. Así que intentemos esto de nuevo. Escribamos palabrotas, mira eso, wow, puedo escribir todo lo que quiera. Y luego hay un retraso de tres segundos y luego cambia. Esto nos permite decirle a React de manera más detallada que esto es importante. Eso puede esperar. También podemos, si recapitulamos, decidir de manera más detallada dónde ocurre el cargador con suspense. Y eso es render-as-you-fetch, donde React realmente pausará donde se solicitan los datos y continuará por el árbol y luego, cuando los datos estén listos, volverá y se renderizará allí. Estas son consideraciones que tendrás cuando trabajes con datos a gran escala en React, ¿por qué? Porque puede ensuciar tu interfaz de usuario e introducir tartamudeo. Muy bien, recapitulemos y terminemos. ¿Qué hemos aprendido? Hemos aprendido sobre las tres formas de obtener datos en React hasta ahora. Render-than-fetch, fetch-than-render, render-as-you-fetch.

Los vimos en la práctica. No tuvimos tiempo para verlo en el lado del servidor, pero eso es una charla de 20 minutos. Pero renderizado a medida que se obtienen los datos también funciona en el lado del servidor. También vimos la infraestructura de data a gran escala. Y no sé, siento que ha sido bueno.

Entonces, ahora, la última pregunta, ¿cómo usamos todo esto? No haces lo que te mostré aquí. Esto es solo para entender. Hay una biblioteca. Confía en ellos. Next.js. Remix. O un framework, debería decir. Por lo general, quieres apoyarte en los hombros de los gigantes, como todos hacemos. Como dijo Taz, la community está en todas partes. Y con eso, quiero desearte feliz codificación y muchas gracias por tenerme en el escenario hoy. un merecido aplauso. ¿Sabías que una vez escribí un software completo para que pareciera que soy bueno en la codificación en vivo? Y en realidad lo estás haciendo mejor que mi software falso, así que eso es increíble.

Muy bien, tenemos algunas preguntas de Slido. Así que vamos directo al grano. Y también, por cierto, aquí en esta sala, si te estás moviendo entre pistas, ¿podríamos hacerlo en silencio para que la parte trasera de la sala también pueda escuchar las preguntas? Muchas gracias. Muy bien. ¿Podrías usar memo en lugar de reemplazo de recurso cuando cambia la cadena de búsqueda para evitar renderizados dobles? Probablemente. No lo sé. No lo he intentado. Te animo a que lo intentes y me lo hagas saber. Genial. ¿Hay alguna opción similar para hacer renderizado a medida que se obtienen los datos antes de React 18? Hasta donde sé, no. Quiero decir, en React, hubo algunas versiones experimentales antes de React 18 en las que se podía hacer eso. Pero las características concurrentes son nuevas. La parte 18 es porque es un cambio rompedor, por así decirlo.

No creo que sea así. Todo esto de lo que hablaste. Está en el RFC. Está en la documentation. Correcto. Exactamente. ¿Cuál es el estado del RFC ahora? ¿Está listo para su uso en producción? Creo que es más una intención de implementar en lugar de implementado. Correcto. Pero la intención está ahí. De acuerdo. Genial.

¿Qué hay de hacer fetch en un controlador de eventos como onclick para navegar? ¿Es esto renderizar a medida que se obtienen los datos? Podría ser. Sí, creo que sí. Realmente no lo sé. Es hacer fetch y luego renderizar. Gracias, Philip. Él estuvo en mi masterclass. Él sabe cosas. Es decir, onclick en un controlador de eventos es hacer fetch y luego renderizar. Así que no. Muy bien.

Bueno, creo que estas son todas las preguntas que tuvimos de Slido. Increíble. Damos un gran agradecimiento a Tejas.