Pasamos mucho tiempo discutiendo qué biblioteca de estado deberíamos usar, y es justo. Hay bastantes, desde la común que todos usan y aman odiar, hasta esa alternativa peculiar, hasta varios recién llegados. Sin embargo, discutir cuál biblioteca es la mejor pone el carro antes que el caballo.
Al averiguar cómo manejar el estado, primero deberíamos preguntarnos: ¿qué diferentes categorías de estado necesitamos? ¿Cuáles son las restricciones de cada categoría? ¿Cómo se relacionan entre sí? ¿Cómo se relacionan con el mundo exterior? ¿Cómo evitamos que se conviertan en una gigantesca y frágil bola de hilo? Y más.
Esto puede sonar abrumador, ¡pero no temas! En esta charla, te guiaré sobre cómo responder estas preguntas y cómo elaborar un sistema de estado accesible, mantenible y escalable. Y sí, también hablaré sobre cómo elegir una biblioteca de gestión de estado.
This talk has been presented at React Summit US 2023, check out the latest edition of this React Conference.
FAQ
El estado se define como los datos y todos sus mecanismos relacionados, incluyendo cómo se accede, se lee, se actualiza y se sincroniza la información.
Brian identifica tres categorías principales: datos de arranque (creados antes del inicio), datos cargados perezosamente (carga diferida necesaria para mostrar UI) y datos reactivos (que responden a la interacción del usuario).
La categoría del estado informa la estrategia de testing necesaria, determinando qué tipo de pruebas y salvaguardias son necesarias para asegurar la integridad y funcionalidad del estado.
Brian menciona varias bibliotecas de gestión de estado como Redux, Recoil, Jotai y Zustand, destacando sus diferentes enfoques y adecuaciones según los tipos de datos que manejan.
Un dato regional es un tipo de dato que no es global ni local, sino que tiene relevancia dentro de un alcance más limitado pero no se limita a un único componente, ideal para ciertas áreas o páginas específicas de una aplicación.
Brian utiliza el término 'localidad de los datos' para diferenciar entre datos locales (usados por un solo componente), globales (necesarios en toda la aplicación) y regionales (relevantes para múltiples componentes pero no globalmente).
Brian sugiere invertir temprano en la estructura de los sistemas de gestión de estado y facilitar hacer lo correcto mientras se hace difícil hacer lo incorrecto, para guiar a los desarrolladores hacia prácticas más seguras y eficientes.
Esta charla discute varios aspectos de la gestión de estado en el desarrollo de software. Cubre diferentes tipos de estado, como datos de arranque, datos cargados de manera perezosa y datos reactivos. La charla también explora el concepto de localidad en la gestión de estado, incluyendo el estado local, global y regional. Introduce bibliotecas como Recoil y Jotai que desafían el concepto de tienda global única y proporcionan una mejor localidad. La charla enfatiza la importancia de configurar los sistemas de gestión de estado para el éxito y crear sistemas confiables para centrarse en la satisfacción del usuario.
Hola a todos. Mi nombre es Brian Hughes, y soy un ingeniero de frontend en Patreon. Hoy quiero hablar sobre algunas cosas que he aprendido a lo largo de los años sobre cómo construir soluciones exitosas de gestión de estado dentro de las aplicaciones. El estado no es solo datos, es cómo accedemos, leemos, actualizamos y sincronizamos los datos. Es más que solo bibliotecas, es toda la casa. Al diseñar una solución de gestión de estado, una pregunta importante que hacer es ¿cuándo se crea el estado? Hay tres categorías de estado: datos de arranque, estado previo a la interacción y estado dinámico.
Hola a todos. Mi nombre es Brian Hughes, y soy un ingeniero de frontend en Patreon. En Patreon, estoy en un equipo llamado plataforma de frontend, y nuestro equipo tiene la tarea de gestionar básicamente todas las bases para nuestro código de frontend. Y esto incluye architecture y la state management. Y hoy quiero hablar sobre algunas cosas que he aprendido a lo largo de los años sobre cómo construir soluciones exitosas de state management dentro de las aplicaciones. Porque creo que esta es una parte realmente crítica para tener un exitoso código de frontend. También es una que tiende a estar poco invertida.
Comencemos con la definición. ¿Qué es el estado? Así que defino el estado como data y todos sus mecanismos relacionados. Sabemos que intrínsecamente creo que el estado no es solo data, ¿verdad? Data es solo un montón de, bueno, data. Realmente es cómo estamos accediendo a esos data? ¿Cómo estamos leyendo esos data? ¿Cómo los estamos actualizando? ¿Cómo estamos sincronizándolos? Entonces, el estado es realmente su data y todos esos mecanismos asociados con él. Los mecanismos son más que solo bibliotecas. Creo que muchas veces cuando pensamos en el estado, decimos, bueno, tenemos este esquema de API que viene de nuestro backend y nos dice qué data tenemos. Y elegimos la biblioteca de state management Redux, recoil, Jotie, lo que sea, y eso es todo, ¿verdad? Pero eso no es todo. Esos son partes realmente importantes. La forma en que me gusta pensar en ello es que nuestro esquema de API, qué data devuelve el backend y las bibliotecas que usamos para acceder a estos data, eso es como la base de una casa. Es realmente crítico, por supuesto, es la base. Pero también necesitamos paredes y un techo y cosas así también. Y una verdadera solución de state management en una aplicación de frontend, especialmente cualquier aplicación realmente razonablemente compleja es que tenemos que pensar en esto de manera holística, tenemos que pensar en toda la casa. Así que siempre que estoy diseñando una solución de state management, ya sea si es para una aplicación completamente nueva, reescribiendo una antigua, o incluso si es solo agregar una nueva página a un sistema ya existente, hay un puñado de preguntas que realmente me gusta hacerme. Y solo tenemos tanto tiempo hoy, así que solo me voy a quedar con dos de las más importantes o al menos que creo que son importantes, y también creo que no se habla tanto como desearía que se hiciera. Entonces, la primera pregunta es, ¿cuándo se crea el estado? Si pensamos en una aplicación de frontend, no es una instantánea en el tiempo, ¿verdad? Existe a lo largo del tiempo y cambia y reacciona a la entrada del usuario, ¿verdad? Entonces, ¿cuándo está entrando en existencia el estado? Entender eso realmente informa qué tipo de estrategia de testing necesitamos para ello, qué tipos de salvaguardias necesitamos para acceder y todo tipo de cosas. Y realmente depende de la respuesta a esta pregunta. Y creo que hay aproximadamente tres categorías de estado cuando se trata de esta naturaleza temporal. La primera categoría es el estado que se crea antes del inicio, también conocido como data de arranque. Y cuando pensamos en esto, tomaremos, por ejemplo, un sitio de redes sociales. Usaremos eso como ejemplo a lo largo de esta charla. En un sitio de redes sociales, cargamos la página, lo primero que hacemos es ver un montón de publicaciones. Eso es algo que existe antes de que podamos comenzar a interactuar. Y esto sucede, o al menos una forma en que se puede hacer es que podemos hacer esto como parte de data de arranque en un moderno
2. Ensamblaje de Datos y Trampas
Short description:
En Next.js, los datos para el primer renderizado se ensamblan llamando a múltiples puntos finales de la API del back-end y luego iniciando la aplicación. Sin embargo, la creación y el consumo de datos están desacoplados, y necesitamos mantenerlos sincronizados. Los datos pasan por múltiples pasos y se canalizan, pasando por diferentes lugares antes de ser accedidos. Aunque implementar esto no es complicado, todavía requiere escribir y mantener código, lo que conlleva un costo.
configuración de renderizado del lado del servidor. Digamos con Next.js. Y en este mundo, la idea es que primero, ensamblamos todos los data necesarios para hacer ese primer renderizado. Sabes, llamamos a nuestro back-end, generalmente a múltiples puntos finales de la API del back-end, y podríamos hacer algo de hidratación, masajeo de data. Ensamblamos todo eso, y solo entonces, una vez que hemos terminado de hacer eso, hacemos iniciar la aplicación y hacer ese primer renderizado. Y así hay un par de trampas para estar al tanto de esto. Y como mencioné, esta creación de data y el consumo de data, están bastante desacoplados. La forma en que data se ve, por ejemplo, en Next.js en lugar de eso función get-server-side-props, la forma en que trabajamos con ella, cómo se ve y todo suele ser diferente a cuando lo leemos desde, digamos, dentro de Redux o algo así. Y así solo necesitamos tener en cuenta que estos están desacoplados, y por lo tanto nosotros necesitamos pensar en mantenerlos sincronizados. Ahora, en realidad no es tan complicado hacerlo en la práctica. Usualmente TypeScript es una gran solución para esto, pero aún es algo que tenemos que pensar, y por lo tanto también tenemos que mantener. Otro poco de trampa con esto es que estos data pasan por un par de pasos y se canalizan. Como dije, comenzamos llamando a múltiples puntos finales para buscar diferentes, a menudo bits de data no relacionados. Estamos buscando quién es el usuario actual, cuál es la lista de más publicaciones recientes, cuáles son los temas de tendencia actuales, cosas así. Y tomamos todos los data dispares y los apretamos juntos en una bola. Y lo pasamos a través de un par de lugares diferentes. Entra en nuestro componente de nivel superior, lo pasamos a nuestras bibliotecas a Redux digamos cuando estamos inicializando nuestra tienda, solo entonces para lo descomponemos y lo accedemos más tarde. Y de nuevo, esto no es particularmente complicado para implementar, pero es código. Y cada vez que implementamos, tenemos que escribir código para hacer algo. No importa cuán simple sea ese código, sigue siendo código que debe mantenerse y sigue siendo código
3. Datos Cargados Perezosamente y Trampas
Short description:
El siguiente tipo de datos son los datos cargados perezosamente. Son datos que no están presentes para el renderizado inicial de la aplicación pero son necesarios para mostrar algo de UI. En un mundo perfecto, cargaríamos todos los datos a la vez, pero en realidad, los cargamos en fragmentos. Esto requiere que los componentos tengan una inteligencia adicional y manejen los estados de carga. Los datos cargados perezosamente también tienen posibles implicaciones de SEO, requiriendo un código especial para la optimización de motores de búsqueda.
que puede tener un error, y por lo tanto, conlleva un costo. Entonces, el siguiente tipo de data es el cargado perezosamente data. Que yo considero como data de inicio diferido. Estos son data que no están presentes para el renderizado inicial de la aplicación, pero aún son necesarios para comenzar a mostrar un poco de UI. Y la forma en que me gusta pensar en esto es, si viviéramos en un mundo perfecto donde los servidores tuvieran memoria infinita, las consultas a la database siempre tomaran cero milisegundos, las cosas se transfirieran por el internet también en cero milisegundos, sin retrasos, nada de eso, los data cargados perezosamente serían data de inicio. En nuestro ejemplo de las redes sociales, en esa página de inicio, en ese feed, cargaríamos cada una de las publicaciones para el feed de todos los tiempos, todas a la vez, ¿verdad? Y simplemente renderizaríamos eso al principio. Por supuesto, en la práctica, no podemos hacer eso. Eso es demasiado data, especialmente si no va a ser visto. Entonces, en su lugar, cargaremos un fragmento a la vez, el usuario desplazará un poco, luego cargaremos un fragmento más y un fragmento más. Entonces, esto es realmente interesante en que conceptualmente, realmente es exactamente lo mismo que los data de inicio, en que estos son data que se necesitan para comenzar a mostrar la UI al usuario. Pero mecánicamente, se ven completamente diferentes. Como resultado, las trampas también son diferentes. Y entonces en esto los componentes necesitan una inteligencia extra, ¿verdad? En el mundo de inicio, el componente recibe los data, renderiza los data, y ya está. Pero ahora los componentes necesitan saber, bueno, ¿en qué estado estamos? Es como, ¿estamos en el proceso de carga y eso es lo que necesitamos mostrar, ya sabes, un spinner o un componente fantasma o algo así? ¿Este componente también necesita ser el que inicie la solicitud? ¿Necesita gestionar esa solicitud? De repente, estos componentes tendrían que hacer mucho más trabajo. Y también los elementos cargados perezosamente no se ejecutan en el renderizado del lado del servidor por definición. Y esto tiene posibles implicaciones de SEO también, ¿verdad? Si SEO necesita tener esos data cargados perezosamente para entender los sitios que obtienes, ya sabes, para que otros o los rastreadores web entiendan eso, discúlpame, para que podamos obtener una correcta optimización de motores de búsqueda. Bueno, ahora de repente, tenemos que escribir un código especial para manejar este caso de SEO. Y de nuevo, este código puede ser simple. Pero el código simple sigue siendo código que tiene que ser mantenido, que puede tener errores y fallar,
4. Datos Reactivos y Alcance del Estado
Short description:
El último tipo de datos es lo que llamo datos reactivos. Este es un estado que responde a la interacción de un usuario con el sitio web. Las trampas en la sincronización del estado pueden convertirse en un verdadero desafío, especialmente con las publicaciones modernas que tienen contenido rico. Manejar interacciones con el servidor que tienen latencia y pueden acumularse unas encima de otras requiere una escritura de código cuidadosa. Definir el tipo de datos e identificar su alcance son cruciales en la gestión del estado.
¿verdad? Así que todavía hay un costo para ello. El último tipo de data es lo que llamo datos reactivos. Y estos no son data que se necesitan para mostrar la UI. Este es un estado que responde a la interacción de un usuario con el sitio web. Así que creo que el mejor ejemplo de las redes sociales, es componer una nueva publicación, ¿verdad? Presionamos un botón, normalmente se abre un editor, y tenemos que mantener un montón de estado alrededor de eso, ¿verdad? Tenemos que mantener tu ¿qué es lo que el usuario escribe? Bueno, no hay forma de que podamos saber esto de antemano, ¿verdad? Lo único que podemos hacer es esperar a que el usuario nos cuente los detalles al respecto, ¿verdad? No tenemos una máquina del tiempo, después de todo. Así que de nuevo, las trampas parecen bastante diferentes. Aquí es donde empezamos a meternos mucho más en la sincronización del estado. Aquí es donde esto puede convertirse en un verdadero desafío, especialmente con la forma en que se ven las publicaciones modernas, que tienen todo tipo de contenido rico en ellas, ¿verdad? Podemos adjuntar archivos. Cuando adjuntamos un archivo, normalmente empezamos a subirlo al servidor en segundo plano. Podemos mencionar a personas. Así que escribes añadir, empiezas a escribir unas pocas letras, y obtendremos una autocompletación. Eso implica varias rondas al servidor. Lo mismo si queremos añadir etiquetas o cualquier otra cosa. Así que obtenemos todas estas interacciones con el servidor que tienen latencia, y que incluso pueden acumularse unas encima de otras. Así que tenemos que escribir nuestro código de tal manera que pueda manejar todas estas diferentes combinaciones. Así que una vez que llegamos aquí, el servicio de testing se vuelve mucho, mucho más grande. Porque con los datos cargados perezosamente y con los datos de inicio, hay prácticamente una sola opción. Quiero decir, podrías tener un par de variantes de data, pero realmente no interactúan entre sí. Mientras que en este rol, tenemos que pensar, ¿cuáles son todas las — no solo testing qué son las cosas básicas, sino cuáles son todas las posibles combinaciones que pueden ocurrir a la vez? Bueno, esto se vuelve bastante más complicado. Pero es realmente interesante mirar hacia atrás en estos tipos, porque todos tienen similitudes y diferencias también. Conceptualmente hablando, los datos cargados perezosamente y los datos de inicio son lo mismo y los datos reactivos son realmente diferentes. Mecánicamente hablando, los datos cargados perezosamente y los datos reactivos son realmente similares y los datos de inicio son diferentes. Así que es como, todos tienen similitudes y todos tienen diferencias. Y creo que es por eso por lo que es realmente importante cuando estamos definiendo el estado identificar realmente qué tipo de data estamos trabajando y cuál de estos tres es. Así que la siguiente pregunta que me gusta hacerme es, ¿dónde se usa el estado? Empezamos con cuándo y ahora estamos en dónde. Y otra forma de decir esto es, ¿cuál es el alcance del estado? Así que primero hablemos de la localidad de los data. Esta es la frase que me gusta usar con ella. Creo que todos conocemos el concepto de datos locales y datos globales. Lo usamos todo el tiempo. Creo que hay un tercer tipo aquí que llamo regional. Vamos a poner un alfiler en eso
5. Tipos de Estado: Local, Global y Regional
Short description:
Vamos a hablar sobre el estado local y global. El estado local es específico para un componente y no necesita ser conocido por el resto de la aplicación. Los datos globales, por otro lado, son accesibles en todas partes y son cruciales para características como la autenticación de usuarios. También existe un tercer tipo llamado datos regionales, que se sitúa entre lo local y lo global. Está acotado a una parte específica de la aplicación, como la página de inicio, pero no se limita a un solo componente.
aunque. Vamos a hablar primero sobre lo local y lo global. Entonces, el estado local, es un estado que solo un componente necesita conocer. No tiene sentido que el resto de la aplicación lo conozca. Por ejemplo, en nuestro editor de publicaciones, a medida que vamos escribiendo valores, no tiene ningún sentido que la barra de navegación o la lista de temas de tendencia o cualquier otra cosa sepa sobre el estado actual de lo que el usuario ha escrito. Eso es realmente solo local, solo ese componente lo necesita. Por otro lado, tenemos datos globales. Creo que el más común global y el mejor ejemplo de esto es ¿quién es el usuario actual? Es posible que ese valor sea nulo si nadie ha iniciado sesión, pero eso sigue siendo data. Y esto es algo que en todas partes del sitio necesita saber. La barra de navegación necesita saberlo para mostrar el avatar del usuario con una opción de cierre de sesión. Un editor de respuestas también necesita saber esto, porque normalmente mostramos ese avatar allí. La página de configuración también necesita saber algo sobre esto. Así que estos son data que realmente necesitan ser accedidos en todas partes. Y así que cuando estamos diseñando global data, tenemos que pensar en ello un poco diferente, porque ya no está acoplado. Así que tenemos que soportar todos estos posibles diferentes casos de uso.
Hay un tercer tipo. Y tuve que inventar mi propio término para esto. Llamo a esto datos regionales, principalmente porque simplemente no veo a la gente hablando de esto. Pero tal vez haya un mejor término para ello. Un dato regional se sitúa, como su nombre lo indica, en algún lugar intermedio. Estos son data que realmente no tienen sentido para toda la aplicación. Tal vez incluso no tiene sentido para la mayoría de la aplicación. Pero tampoco tiene sentido para un solo componente. Y veo esto más en el mundo moderno de las aplicaciones, donde ya no somos realmente una aplicación de una sola página ecosystem más. Como esto no es lo que Next.js y React components y todos esos mecanismos son. Son como aplicaciones de varias páginas, pero también parecen aplicaciones de una sola página. Así que podemos tener algún estado. Por ejemplo, esa lista de publicaciones, tiene mucho sentido en la página de inicio. Pero eso no tiene ningún sentido si estamos revisando el perfil de un usuario específico. Especialmente no tiene sentido si estamos en la página de configuración. Así que este es el estado que realmente está acotado solo a la página de inicio pero es lo suficientemente amplio como para que no esté acotado solo a un solo componente.
6. Desafíos con Datos Regionales y Mecanismos
Short description:
Los gestores de estado a menudo enfrentan desafíos al tratar con datos regionales. El enfoque común de tener todos los posibles datos en todas las páginas y configurarlos en nulo si no se necesitan no es convincente. El concepto de localidad también se aplica a los mecanismos, donde los mecanismos locales son accesibles por un solo componente, los mecanismos globales pueden ser accedidos por cualquiera, y los mecanismos regionales están limitados a un subconjunto de la base de código.
Y aquí es donde realmente veo la mayoría de los problemas surgir alrededor de los gestores de estado. ¿Qué hacemos con estos datos regionales? La respuesta común, especialmente en el mundo de Redux, que realmente, realmente le gusta los datos globales, es simplemente tener todas las posibles piezas de datos en todas las páginas y simplemente configurarlos en nulo si no estamos en esa página. Pero nunca encontré eso una solución muy convincente. Hablé sobre la localidad de los datos, ¿verdad?, y uso esa palabra a propósito porque si volvemos a nuestra definición de estado, el estado es datos más mecanismo. Y resulta que en realidad tenemos la misma taxonomía para los mecanismos también. Y el concepto es el mismo, local es donde el mecanismo solo es accesible por un solo componente. Global significa que cualquiera puede acceder al mecanismo. Regional significa que solo un subconjunto de la base de código puede acceder a ese mecanismo.
7. Tipos de Localidad y Bibliotecas
Short description:
Para diferentes tipos de localidad, se destinan diferentes bibliotecas. useState y useRef se utilizan para datos locales, mientras que Redux y Zustand encarnan la arquitectura Flux y proporcionan un único almacén global para los datos. Sin embargo, la relación entre los datos y el mecanismo no siempre es uno a uno.
Y entonces, para la primera pregunta, sabes, realmente no hablé mucho sobre bibliotecas específicas porque en verdad, todas las diversas bibliotecas que existen soportan esos diferentes casos de uso. Bueno, una vez que empezamos a hablar de localidad, es ahí donde las cosas cambian un poco. Aquí es donde realmente empezamos a ver donde diferentes bibliotecas están realmente destinadas para diferentes tipos de localidad. Así que, vamos a sumergirnos en algunos ejemplos para entender realmente de qué estoy hablando. Vamos a empezar con useState y useRef. Estos son, ya sabes, incorporados en React. Creo que todos los conocen. Ciertamente, useState especialmente. Y esto se utiliza explícitamente para los data locales. De hecho, lo que pasa con useState es que obtuve esta idea completa para, ya sabes, data más mecanismo de useState en sí mismo porque eso es lo que es. useState devuelve un array con dos elementos. El primer elemento son los data. El segundo elemento es el mecanismo para actualizar esos data, ¿verdad? Así que, es como si esta dicotomía estuviera incrustada allí, pero es puramente local por naturaleza. Así que, si lo piensas, esto se devuelve. Vive dentro de un componente. Estos no son variables globales. Sólo existen dentro de ese único componente. No hay manera de que un componente completamente diferente importe esa variable o algo así, ¿verdad? No es así como funciona JavaScript. Así que, es realmente sólo para data locales. Y luego, en el extremo opuesto, tenemos Redux y Zustand. Ambos encarnan lo que se llama la arquitectura Flux. Ambos tienen el concepto de un único almacén global para todos nuestros data. Y realmente lo es. Ambos los data y los mecanismos son verdaderamente globales. Si queremos acceso a esos data, importamos el hook de use store de Redux y podemos acceder a cada pieza de data global en esa única tienda. Y allí realmente es sólo una tienda. Casi siempre, de hecho. Así que, esto es como la quintaesencia de los data globales. Así que, hasta ahora con estas dos opciones, hemos visto una relación uno a uno entre los data y el mecanismo. Así que, podría ser tentador pensar que siempre son uno a uno, pero resulta que
8. Recoil y Jotai: Microalmacenes para una Mejor Localidad
Short description:
Recoil y Jotai son dos bibliotecas más nuevas en el mundo de la gestión de estado que desafían el concepto de almacén global único utilizado por Redux y Zustand. En lugar de un único almacén global, estas bibliotecas crean microalmacenes llamados átomos. Cada átomo es responsable de una sola pieza de estado. Esto permite una mejor localidad en la gestión del estado.
no siempre. Y las próximas dos bibliotecas de las que voy a hablar, finalmente empezamos a ver esto romperse. Y eso es Recoil y Jotai. Así que, estas dos bibliotecas son mucho más nuevas en el mundo de la state management. Así que, si no estás familiarizado con ellas, sólo para que lo sepas rápidamente, lo que hacen es decir, sabes, esta idea de un único almacén global que, como, sabes, Redux y Zoostand usan, tal vez en realidad no sea la mejor manera de hacerlo. Así que, en lugar de tener un único almacén global, vamos a crear un montón de básicamente microalmacenes. Y a estas cosas las llaman átomos. Y así, un solo átomo es responsable básicamente de una sola pieza de estado. Así que, por ejemplo, habría un átomo de usuario actual. ¿Verdad? Y eso es todo lo que hay. Y podría haber un átomo completamente separado o un conjunto de átomos para, sabes, todas las publicaciones en el feed de Inicio. Y de nuevo un conjunto separado de átomos para la lista de temas de formación, sabes, y así sucesivamente. Y en la práctica, a menudo hay bastante más que eso. Así que, cada uno de estos átomos es sólo responsable de esa única pieza de estado y nada más. Y así es donde nosotros
9. Jotai: Mecanismos Locales y Globales
Short description:
Con Jotai, podemos crear mecanismos locales para acceder a datos compartidos en componentes. Los átomos contienen el estado y la lógica de negocio, permitiendo efectos secundarios y llamadas a la red. Los átomos no utilizados no se incluyen en el paquete, proporcionando un mecanismo regional. Jotai también puede ser utilizado para datos globales, como un átomo de usuario actual.
empezamos a, bien, volvamos a la localidad ahora. Con eso en mente, es aquí donde las cosas se vuelven, creo, muy interesantes. Es por eso que personalmente soy un gran fan de esto. He estado usando Jotai últimamente y realmente lo estoy disfrutando. Porque con esto, podemos construir nuestro código de tal manera que digamos que tenemos un archivo con un componente en él y necesita acceso a algunos data que no son locales a ese componente. Existe en todos los componentes. Hay casos de uso para esto. Pero podemos crear un átomo para mantener ese estado y podemos pegarlo en ese mismo archivo como el componente y luego nunca exportarlo. Así que, lo que eso significa es que en la práctica, de repente tenemos este átomo que sólo puede ser accedido por un componente, es decir, podemos tener un mecanismo local para acceder a estos data con Jotai, que es algo que no podemos hacer con Redux. Ahora, todavía no obtenemos datos locales porque esos data de nuevo, se comparten en todos los componentes. Pero es un mecanismo local que es realmente interesante. También fue la primera vez que empezamos a ver la aparición de algo que empieza a acercarse a los datos regionales. Otra cosa que creo que es muy ingeniosa con Recall en Jotai es que, tenemos estos átomos, no sólo contienen el estado, también tienen la lógica de negocio de cómo interactuamos con él. Podemos tener efectos secundarios y todo tipo de otras cosas. Podemos hacer llamadas a la red relacionadas con él. Así que podemos tener toda esta lógica, tenemos estos mecanismos aquí para trabajar con ciertos tipos de estado. Y si hay, digamos, una página, y ningún componente en esa página importa ese átomo, ese código ni siquiera aparece en el paquete. No está allí en absoluto. Así que si tenemos un átomo para mantener, digamos, información de autenticación de dos factores, esto existe en la página de configuración. La página de inicio nunca lo importa. Ese código, ni siquiera está en el paquete. Nunca se envía al cliente. Así que en realidad tenemos lo que parece un mecanismo regional. Digo que esto es sólo un mecanismo regional-ish, porque no hay ninguna aplicación de esto. No había nada que impidiera a un componente en la página de inicio importar ese átomo 2FA. Que es más o menos lo que realmente queremos tener. Pero aún así, nos acerca. Está al menos más cerca, lo que creo que lo hace realmente atractivo. Y por supuesto, estos también pueden ser utilizados para datos globales. Puedes tener, de nuevo, un átomo de usuario actual. Todo el mundo lo importa
10. Datos Regionales y Contexto de React
Short description:
El contexto de React permite la creación de tantos contextos como sea necesario, que se pueden colocar en cualquier lugar del árbol de componentes. Al limitar el contexto a un árbol de componentes específico, se pueden crear datos regionales. Sin embargo, el mecanismo sigue siendo solo regional-ish debido a los mecanismos de módulo en JavaScript, que no tienen el concepto de regionalidad. Se puede utilizar Linting para gestionar las importaciones y prevenir el acceso al contexto desde fuera del árbol de componentes.
en todas partes. Simplemente funciona. Así que esto plantea la pregunta, bien, hemos hablado de cosas diferentes. Hemos visto buenos ejemplos de local. Hemos visto buenos ejemplos de global. Estos están empezando a entrar en lo regional, pero no realmente. Así que la pregunta es, ¿puede algo hacer realmente datos regionales? Especialmente porque, de nuevo, no se habla realmente de ello. Resulta que sí. Y eso es el contexto de React. Así que el contexto de React en sí se utiliza para alimentar todos esos bibliotecas. Se sientan debajo del capó de Recoil, Zoostand, y un montón de otros. Pero lo que encuentro tan convincente acerca del contexto de React que esas bibliotecas no ejercen realmente es que puedes tener tantos contextos de React como quieras y pegarlos en cualquier lugar de tu árbol de componentes. Así que para esos datos de autenticación de dos factores, podríamos poner eso dentro de un contexto de React, y sólo inicializamos el contexto en un componente para la página de configuración que no se utiliza en ningún otro lugar. Algo así como un envoltorio de página donde empezamos esto . Así que cuando eso sucede, eso significa que tienes que estar dentro de ese árbol de componentes para acceder a este contexto. Está simplemente incorporado. Si intentas acceder a ese contexto desde fuera de ese árbol de componentes, obtienes una excepción. Así que eso significa que ahora podemos crear datos regionales al limitar a nuestro árbol de componentes, lo cual es realmente genial. Ahora, el mecanismo sigue siendo sólo regional-ish por la misma razón que recall y Jota. No hay nada que nos impida importar en todas partes del código. De hecho, voy a salir tal vez en una rama aquí. Dejaré que todos ustedes decidan. No creo que sea posible tener un mecanismo regional en JavaScript hoy en día, y eso se reduce a nuestros propios mecanismos de módulo. Como common.js no tienen este concepto de regionalidad. Es si algo se exporta, cualquier código en cualquier lugar puede importarlo. No hay nada que podamos hacer al respecto. Podemos hacer capas en la parte superior. Me gusta usar linting para prevenir esto. Tuvimos que escribir una regla de lint personalizada. Tenemos una regla de lint personalizada que dice quién es
11. Gestión del Estado Regional y Mejores Prácticas
Short description:
Los contextos de React son un mecanismo de bajo nivel que no pretende ser una solución completa de gestión de estado. Fueron inventados para apoyar a otras bibliotecas de gestión de estado. Creé una biblioteca llamada ReactStrap para acceder a datos de inicio regional. La gestión del estado regional es un área propicia para la innovación. Facilita hacer lo correcto y dificulta hacer lo incorrecto al configurar sistemas de gestión de estado.
permitido importar qué. Eso nos ayuda a gestionarlo. Ahora, hay otro problema con el contexto de React. Tal vez no exactamente un problema, pero algo de lo que hay que estar consciente. Es un mecanismo bastante básico. Los contextos de React no estaban destinados a ser una solución completa de gestión de estado. Fueron inventados para ayudar a apoyar estas otras bibliotecas de gestión de estado. Están destinados a ser construidos encima de ellos.
Creo que hay una verdadera oportunidad aquí para empezar a explorar esta área de estado regional. Creé una biblioteca para hacer exactamente eso. Acabo de crearla y lanzarla mientras grabo esto, hace apenas unos días. La llamo ReactStrap. Es muy limitada y de propósito especial. Está destinada para acceder a datos de inicio regional. Animo a la gente a echarle un vistazo. Ya sea que la uses o no, quiero que pienses en lo que estamos tratando de hacer aquí. Creo que este concepto de gestión de estado regional es un área propicia para la innovación. Espero que la gente pueda empezar a invertir más en bibliotecas, herramientas, patrones, incluso mecanismos de pruebas. Por lo tanto, es una parte crítica de la mayoría de las aplicaciones web modernas. Así que quiero terminar esta masterclass con un poco de consejo para las personas que están configurando sistemas de gestión de estado. Primero, un mantra que aprendimos de un equipo de plataforma diferente, facilita hacer lo correcto y dificulta hacer lo incorrecto. Si podemos hacer eso, es así como guiamos a las personas por el camino correcto. Y tendemos a obtener sistemas más fiables como resultado. ¿Qué quiero decir con eso? Un buen ejemplo de hacer difícil lo incorrecto es la regla de lint. Cuando tenemos una regla de lint, dice que no se te permite hacer esto. Hace difícil hacer lo incorrecto. No tiene nada que ver con facilitar hacer lo correcto. Dice no hagas esto. No dice haz esto. ¿Verdad? Pero un ejemplo de facilitar hacer lo correcto, es un patrón del que soy un gran fan
12. Reflexiones Finales sobre la Gestión del Estado
Short description:
En Patreon, tenemos un hook llamado use current user. No toma argumentos. Si necesitas usar un usuario actual, importas el hook, lo llamas, y lo tienes. Invierte temprano y no implementes sistemas de estado ad hoc. Piensa en todo lo que he hablado. Prepara a los ingenieros para el éxito y no para el fracaso. Eso es lo que hace un buen sistema de gestión de estado. Eso es lo que hace un buen código en general. Cuando pensamos en estos sistemas, ¿cómo podemos ayudar a nuestros compañeros ingenieros a tener éxito? Una vez que hacemos eso, es cuando creamos sistemas mejores, más confiables y podemos centrarnos en las características y en hacer felices a nuestros usuarios.
para los datos comunes de inicio. Digamos un usuario actual. Entonces, crearé un hook para ello. En Patreon, tenemos un hook llamado use current user. No toma argumentos. Si necesitas usar un usuario actual, importas el hook, lo llamas, y lo tienes. Es tan increíblemente simple usar esta cosa. Casi no hay razón para usar cualquier otra cosa. El siguiente consejo que tengo es invertir temprano y no implementar sistemas de estado ad hoc. Como mencioné al principio, parece que la mayoría de la gente piensa que tengo mi esquema de API, tengo mi biblioteca. Voy a mostrar todos mis datos y no me preocupo por ello. Sólo cuando surgen problemas, añaden más estructura. Te animo a que lo pienses desde el principio. Piensa en todo lo que he hablado.
Finalmente, el nivel más meta de esta masterclass, lo que quiero que todos se lleven es preparar a los ingenieros para el éxito y no para el fracaso. Eso es lo que hace un buen sistema de gestión de estado. Eso es lo que hace un buen código en general. Todos los mecanismos de gestión de estado pueden ser utilizados para todos los tipos de estado. Podemos usar state y use ref para datos globales, pero no va a ser exitoso. No va a funcionar. Vamos a tener tantos dolores de crecimiento. Cuando estamos pensando en estos sistemas, piensa en cómo podemos ayudar a nuestros compañeros ingenieros a tener éxito? Una vez que hacemos eso, es cuando creamos sistemas mejores, más confiables y podemos centrarnos en las características y en hacer felices a nuestros usuarios. Y con eso, quiero agradecer a todos por escuchar.
State management is not limited to complex applications and transitioning to a store offers significant benefits. Pinia is a centralized state management solution compatible with Vue 2 and Vue 3, providing advanced devtools support and extensibility with plugins. The core API of Pinia is similar to Vuex, but with a less verbose version of stores and powerful plugins. Pinia allows for easy state inspection, error handling, and testing. It is recommended to create one file per store for better organization and Pinia offers a more efficient performance compared to V-rex.
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Global state management and the challenges of placing server state in global state are discussed. React Query is introduced as a solution for handling asynchronous server state. The Talk demonstrates the process of extracting logic into custom hooks and fixing issues with state and fetching logic. Optimistic updates with mutation are showcased, along with the benefits of using React Query for data fetching and mutations. The future of global state management is discussed, along with user feedback on React Query. The Talk concludes with an invitation to explore React Query for server state management.
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Starbeam is a library for building reactive user interfaces with JavaScript, similar to Svelte, Vue, and Ember. It provides a data structure and query feature for filtering and sorting. The useStarBeam function ensures JSX reconciliation only occurs when reactive dependencies change. Starbeam tracks every read and write operation to update the component accordingly. It can be used with React and other frameworks, and offers debugging tools and locale integration.
Let's talk about React and TypeScript, Yarn's philosophy and long-term relevance, stability and error handling in Yarn, Yarn's behavior and open source sustainability, investing in maintenance and future contributors, contributing to the JavaScript ecosystem, open-source contribution experience, maintaining naming consistency in large projects, version consistency and strictness in Yarn, and Yarn 4 experiments for performance improvement.
La distinción entre el estado del servidor y el estado del cliente en nuestras aplicaciones puede ser un concepto nuevo para algunos, pero es muy importante entenderlo cuando se entrega una experiencia de usuario de primera calidad. El estado del servidor viene con problemas únicos que a menudo se cuelan en nuestras aplicaciones sorpresa como: - Compartir datos entre aplicaciones- Caché y Persistencia- Deduplicación de Solicitudes- Actualizaciones en segundo plano- Gestión de Datos "Obsoletos"- Paginación y Recuperación Incremental- Memoria y Recolección de Basura- Actualizaciones Optimistas Los gestores tradicionales de "Estado Global" pretenden que estos desafíos no existen y esto finalmente resulta en que los desarrolladores construyan sus propios intentos sobre la marcha para mitigarlos. En esta masterclass, construiremos una aplicación que expone estos problemas, nos permite entenderlos mejor, y finalmente los convierte de desafíos a características usando una biblioteca diseñada para gestionar el estado del servidor llamada React Query. Al final de la masterclass, tendrás una mejor comprensión del estado del servidor, el estado del cliente, la sincronización de datos asíncronos (un bocado, lo sé), y React Query.
Comienza con la Rejilla de Datos React de AG Grid con un tutorial práctico del equipo central que te llevará a través de los pasos para crear tu primera rejilla, incluyendo cómo configurar la rejilla con propiedades simples y componentes personalizados. La edición comunitaria de AG Grid es completamente gratuita para usar en aplicaciones comerciales, por lo que aprenderás una herramienta poderosa que puedes agregar inmediatamente a tus proyectos. También descubrirás cómo cargar datos en la rejilla y diferentes formas de agregar renderizado personalizado a la rejilla. Al final de la masterclass, habrás creado una Rejilla de Datos React de AG Grid y personalizado con componentes React funcionales.- Comenzando e instalando AG Grid- Configurando ordenación, filtrado, paginación- Cargando datos en la rejilla- La API de la rejilla- Usando hooks y componentes funcionales con AG Grid- Capacidades de la edición comunitaria gratuita de AG Grid- Personalizando la rejilla con Componentes React
Mucho ha cambiado en el mundo de la gestión del estado en React en los últimos años. Donde Redux solía ser la principal biblioteca para esto, la introducción de las API de Contexto y Hooks de React ha revolucionado las cosas. Ya no necesitas bibliotecas externas para manejar tanto el estado del componente como el estado global en tus aplicaciones. En este masterclass aprenderás los diferentes enfoques para la gestión del estado en la era post-Redux de React, ¡todos basados en Hooks! Y como bonificación, exploraremos dos próximas bibliotecas de gestión del estado en el ecosistema de React.
En esta masterclass práctica, Maurice te guiará personalmente a través de una serie de ejercicios diseñados para empoderarte con una profunda comprensión de los Componentes de Servidor React y el poder de TypeScript. Descubre cómo optimizar tus aplicaciones, mejorar el rendimiento y desbloquear nuevas posibilidades.
Durante la masterclass, realizarás: - Maximizar la mantenibilidad y escalabilidad del código con prácticas avanzadas de TypeScript - Desatar los beneficios de rendimiento de los Componentes de Servidor React, superando enfoques tradicionales - Potenciar tu TypeScript con el poder de los Tipos Mapeados - Hacer tus tipos TypeScript más seguros con Tipos Opacos - Explorar el poder de los Tipos de Plantillas Literales al usar Tipos Mapeados
Maurice estará virtualmente a tu lado, ofreciendo una guía completa y respondiendo a tus preguntas mientras navegas por cada ejercicio. Al final de la masterclass, habrás dominado los Componentes de Servidor React, armado con un nuevo arsenal de conocimientos de TypeScript para potenciar tus aplicaciones React.
No pierdas esta oportunidad de elevar tu experiencia en React a nuevas alturas. Únete a nuestra masterclass y desbloquea el potencial de los Componentes de Servidor React con TypeScript. Tus aplicaciones te lo agradecerán.
Únete a nosotros para un masterclass de 3 horas que explora el mundo del desarrollo creativo de React utilizando Codux. Los participantes explorarán cómo un enfoque visual puede desbloquear la creatividad, agilizar los flujos de trabajo y mejorar la velocidad de desarrollo. Sumérgete en las características que hacen de Codux un cambio de juego para los desarrolladores de React. La sesión incluirá ejercicios prácticos que demuestran el poder de la renderización en tiempo real, la manipulación visual del código y el aislamiento de componentes, todo en tu código fuente. Tabla de contenidos:- Descarga e instalación: Preparando Codux para el masterclass- Selector de proyectos: Clonación e instalación de un proyecto de demostración- Introducción a los conceptos principales de Codux y su interfaz de usuario- Ejercicio 1: Encontrando nuestro camino- Descanso- Ejercicio 2: Realizando cambios de manera efectiva- Ejercicio 3: Reutilización y validación de casos especiales- Resumen, Cierre y Preguntas y Respuestas
En Vue moderno tenemos muchas opciones de cómo crear y compartir estado entre múltiples componentes. En este masterclass escribiremos una aplicación utilizando todos los enfoques: Vuex, hooks de la API de composición y Pinia.
Comments