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

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

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.

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.

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

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

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.