Domando el Dragón de la Gestión de Estado

Rate this content
Bookmark

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.

23 min
15 Nov, 2023

AI Generated Video Summary

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.

1. Introducción a la Gestión de Estado

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit Remote Edition 2020React Summit Remote Edition 2020
30 min
React Query: It’s Time to Break up with your "Global State”!
An increasing amount of data in our React applications is coming from remote and asynchronous sources and, even worse, continues to masquerade as "global state". In this talk, you'll get the lowdown on why most of your "global state" isn't really state at all and how React Query can help you fetch, cache and manage your asynchronous data with a fraction of the effort and code that you're used to.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
JSNation 2022JSNation 2022
27 min
Announcing Starbeam: Universal Reactivity
Starbeam is a library for building reactive data systems that integrate natively with UI frameworks such as React, Vue, Svelte or Ember. In this talk, Yehuda will announce Starbeam. He will cover the motivation for the library, and then get into the details of how Starbeam reactivity works, and most importantly, how you can use it to build reactive libraries today that will work natively in any UI framework. If you're really adventurous, he will also talk about how you could use Starbeam in an existing app using your framework of choice and talk about the benefits of using Starbeam as the state management system in your application.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.

Workshops on related topic

React Summit 2020React Summit 2020
96 min
Rethinking Server State with React Query
Featured Workshop
The distinction between server state and client state in our applications might be a new concept for some, but it is very important to understand when delivering a top-notch user experience. Server state comes with unique problems that often sneak into our applications surprise like:
- Sharing Data across apps- Caching & Persistence- Deduping Requests- Background Updates- Managing “Stale” Data- Pagination & Incremental fetching- Memory & Garbage Collection- Optimistic Updates
Traditional “Global State” managers pretend these challenges don’t exist and this ultimately results in developers building their own on-the-fly attempts to mitigate them.
In this workshop, we will build an application that exposes these issues, allows us to understand them better, and finally turn them from challenges into features using a library designed for managing server-state called React Query.
By the end of the workshop, you will have a better understanding of server state, client state, syncing asynchronous data (mouthful, I know), and React Query.
React Summit Remote Edition 2021React Summit Remote Edition 2021
71 min
State Management in React with Context and Hooks
WorkshopFree
A lot has changed in the world of state management in React the last few years. Where Redux used to be the main library for this, the introduction of the React Context and Hook APIs has shaken things up. No longer do you need external libraries to handle both component and global state in your applications. In this workshop you'll learn the different approaches to state management in the post-Redux era of React, all based on Hooks! And as a bonus, we'll explore two upcoming state management libraries in the React ecosystem.
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
React Summit 2023React Summit 2023
31 min
From Idea to Production: React Development with a Visual Twist
WorkshopFree
Join us for a 3-hour workshop that dives into the world of creative React development using Codux. Participants will explore how a visually-driven approach can unlock creativity, streamline workflows, and enhance their development velocity. Dive into the features that make Codux a game-changer for React developers. The session will include hands-on exercises that demonstrate the power of real-time rendering, visual code manipulation, and component isolation all in your source code.
Table of the contents: - Download & Setup: Getting Codux Ready for the Workshop- Project Picker: Cloning and Installing a Demo Project- Introduction to Codux Core Concepts and Its UI- Exercise 1: Finding our Feet- Break- Exercise 2: Making Changes While Staying Effective- Exercise 3: Reusability and Edge Case Validation- Summary, Wrap-Up, and Q&A