setState, ¡Necesitamos hablar!

Antes de comenzar, un poco sobre mí. Para aquellos que no me conocen, hola, soy Nikhil. Soy ingeniero de software en Postman. Principalmente me ocupo de cosas relacionadas con Postman en la web y en la plataforma de escritorio de Postman. También me encanta hablar sobre los sistemas de diseño y el rendimiento en general. Aquí están mis enlaces de Twitter y GitHub. Me encantará conectarme y charlar.

Continuando, comencemos con la idea de que al resolver problemas más complejos, hemos comenzado a desarrollar soluciones más complejas con el tiempo para facilitar la vida de los usuarios, ¿verdad? Es un hecho conocido que en el pasado, no teníamos tantos problemas complejos para resolver. Y tampoco teníamos las herramientas adecuadas y el conjunto correcto de cosas para hacer que nuestras UI sean más ricas y más eficientes como lo tenemos ahora. Y esa es básicamente la razón por la que principalmente teníamos sitios web estáticos y cosas así, donde no necesitábamos ninguna entrada de los usuarios. No esperábamos que los usuarios interactuaran mucho con nuestros sitios web en comparación con lo que tenemos ahora, que son más aplicaciones web donde hay una tonelada de interacción del usuario, ¿verdad?

A medida que el tiempo ha avanzado, los desarrolladores y diseñadores han comenzado a pensar más en la experiencia del usuario y en las soluciones. Y a medida que las cosas se han vuelto más complejas y estamos tratando de resolver problemas más complejos, las soluciones o las UI que estamos construyendo ahora comienzan a volverse más densas y más complejas porque ahora tienen muchas más cosas para ofrecer al usuario, ¿verdad? Con una UI tan rica, los usuarios siempre tienen la oportunidad de sorprendernos, a los desarrolladores, al usar nuestras aplicaciones de muchas formas diferentes que quizás no habíamos imaginado o tenido en cuenta. Un usuario puede usar tu aplicación de formas completamente diferentes que tú no habías pensado y eso destaca la necesidad de que ahora planifiquemos mejor nuestras UI. Ahora es realmente necesario que planifiquemos nuestras UI. Y diría más bien que no solo depende de los usuarios, también depende de nosotros que principalmente seguimos el plan de implementación en lugar del plan de mantenimiento, ¿verdad? Mayormente estamos en este concepto de que, `oye, tengo una UI que construir, déjame ir y definir qué cosas necesito tener, qué efectos necesito ejecutar, qué lógica necesito ejecutar en un onChange y en un input y cosas así`. Estamos más enfocados en los detalles de la implementación en lugar de dar un paso atrás y pensar más en cómo podemos comenzar con el mantenimiento y cómo podemos planificar mejor nuestras UI para que sean más eficientes y más fáciles de mantener en el futuro.

De acuerdo, dicho esto, veamos las cosas en acción considerando un ejemplo muy simple. Como puedes ver, aquí hay un pequeño fragmento de código de un formulario de inicio de sesión básico. Y lo que hace es tener dos campos de texto, un ID de usuario, una contraseña, y luego hay un botón al final en el que haces clic y te inicia sesión o simplemente te muestra un mensaje de error. Si me preguntaras cómo estamos pensando en las UI en este momento, lo primero en lo que nos sumergiríamos es, bueno, hay dos estados. Tenemos nombre de usuario y contraseña, listo y listo. Luego pensamos, bueno, hay una parte asíncrona que tenemos que hacer. Entonces, creemos una función encima de eso para hacer esas cosas asíncronas, que en este caso es hacer clic en un botón y enviar esos datos para poder iniciar sesión. Y en tercer lugar, simplemente pensamos, bueno, hay una UI que debe renderizarse. Entonces, está bien, solo rendericemos dos cuadros de texto, un botón, y listo. Y es posible que estés pensando, oye, hombre, ¿por qué necesitaríamos este tema en primer lugar? Esto es tan obvio de hacer, ¿verdad? Y ahí es donde diría que, oye, esto es algo muy mínimo, ¿verdad? ¿Qué pasa si quiero mostrar un tipo de mensaje de éxito o error en el futuro? Ahora mismo, solo tenemos un campo de texto, un nombre de usuario, una contraseña y luego un botón. Y simplemente hago clic en él, y eso es todo. Entonces, ¿qué pasa si tengo que mostrar ese tipo de mensajes al usuario? De acuerdo, ahora podrías estar pensando que, bueno, ahora el trabajo ha comenzado a desarrollarse en nosotros.

Y ahora vemos que, bueno, dos estados más. No es un problema. Y luego, dentro de nuestra tarea asíncrona, manejamos cómo alternar estos estados. Entonces, como puedes ver en la función del formulario de envío, si todo sale bien para nuestros datos asíncronos, establecemos que esto es éxito en verdadero. Y si no, luego establecemos que hay un error en verdadero. Y dentro de nuestro punto de interfaz de usuario, luego hacemos, bien, si hay un éxito, bien, hemos iniciado sesión correctamente. Y de lo contrario, simplemente mostramos un párrafo que, bien, hay algún error.

Muy bien, intentemos pensar más profundamente en términos de, bien, ¿qué pasa si quiero deshabilitar un botón? Y luego dirías, bien, otra etapa, un poco más de trabajo que hacer en el formulario de envío. Y luego tengo que deshabilitar este botón en este estado de carga basado en este indicador booleano de carga. Y ahora eso es esto, y ahora creo que puedes darte cuenta a dónde voy, ¿verdad? Entonces, en primer lugar, los problemas con este tipo de enfoque son, en primer lugar, esto es difícil de mantener. Estos son solo algunos estados en este momento, pero a medida que este formulario comienza a volverse más complejo y más maduro, habrá una tonelada de estados más y será realmente difícil manejarlos en el futuro ya que la longitud de este código comienza a aumentar tanto. En segundo lugar, hay un concepto llamado explosión de estados, ¿verdad? Entonces, en este momento, solo tengo principalmente tres estados para tener mi interfaz de usuario lista, pero si lo ves en una imagen más amplia, tenemos dos elevado a la potencia tres, eso es ocho permutaciones y combinaciones en las que nuestros estados pueden existir. Básicamente, hay ocho formas en las que una interfaz de usuario puede existir si lo ves matemáticamente. Sinceramente, es posible que no necesites esos estados en ningún otro lugar en el futuro o que no sea necesario manejarlos, pero, oye, el usuario puede acceder a ellos o llegar a ese estado en cualquier otro formulario. Así que tienes que tener eso en cuenta. Y en tercer lugar, y lo más importante, esto es realmente difícil de visualizar, ¿verdad? Porque tu aplicación tiene un alma, que es la lógica de tu aplicación donde estás haciendo esa parte de pensamiento lógico de tu aplicación. Y con esa lógica dispersa, como azúcar esparcido en diferentes partes de tu aplicación, es realmente difícil darle sentido a este código si soy un nuevo desarrollador y comienzo a trabajar en este código. Así que es muy difícil de entender. Y básicamente eso es lo que llamo un código Horcrux. Así que si hay fanáticos de Harry Potter en la audiencia, creo que todos lo saben. Entonces, como este Horcrux, como este es un Horcrux donde seleccionaste estos, que tenían una forma de crear, es como si pudieran mantener una parte de su alma en un lugar y otra parte de esa alma en otro. Entonces eso es lo que está sucediendo dentro de nuestra base de código. Entonces, el alma de nuestra aplicación o el alma de nuestro código, esa es nuestra lógica que se está dispersando en múltiples lugares. Y es por eso que es muy difícil visualizar ese código. Y este es un ejemplo muy pequeño, como todos han visto, tenemos mucha más complejidad en nuestras interfaces de usuario y muchas más características para ofrecer. Y no se trata solo de un formulario de inicio de sesión, sino que es mucho más que eso a medida que nuestras interfaces de usuario se han vuelto tremendamente complejas y grandes. Entonces ahora sabemos eso, ¿verdad? Que la planificación es realmente importante. Y con la planificación puedes hacer que tu código sea mantenible. Puedes detectar errores fácilmente. Puedes hacer que tu código sea más visualizable y eso te ayuda.

Puedes hacer que tu código sea más visualizable y eso te ayuda. Pero, ¿qué estamos haciendo con la planificación, verdad? Mayormente estamos siguiendo el concepto de planificación basada en la implementación, ¿verdad? Y no en la planificación basada en la mantenibilidad. Entonces, con ese ejemplo que mostramos anteriormente, estamos mayormente pensando en, bueno, ¿qué hay en nuestros efectos? ¿Cuáles son las props? ¿Cuáles son los estados y demás? Y eso nos lleva a una conclusión de que ¿qué puede ser una mejor manera, verdad? ¿Qué puede ser una mejor manera de planificar nuestras interfaces de usuario en lugar de planificar la implementación?

Y ahora quizás puedas ver que dado que tenemos muchos estados y puede haber muchas permutaciones y combinaciones de esos estados en el futuro, tiene que haber una manera, o tiene que haber algún tipo de sistema donde podamos evitar estas múltiples declaraciones if else para manejar qué hacer cuando este estado está presente y este estado no está presente. Puede haber un sistema donde simplemente podamos verificar y orquestar nuestros estados y transiciones entre esos estados de una mejor manera. Y obviamente lo adivinaste, ¿verdad? Así es como las máquinas de estado finito nos ayudan.

Entonces, si tuviera que decir esto de una manera más simple lo que las máquinas de estado finito tienen para ofrecer es básicamente tienes un estado inicial o una condición inicial o una situación inicial de la interfaz de usuario, en la que podría estar. Y luego puedes realizar alguna acción con ese estado. Y si ese estado recibe una acción, pasa a un estado siguiente. Y en todo momento, cada estado sabe, según una acción, cuál será el siguiente estado por el que pasará la interfaz de usuario o tu código. Y eso es lo que significan estas tres palabras, ¿verdad? Tienes un número finito de estados. Tienes un estado obviamente, que es una condición o situación en la que se encuentra tu interfaz de usuario. Y básicamente hay una máquina, que está orquestando ese estado y cómo esos estados hacen transiciones basadas en acciones. Entonces, eso es principalmente el punto completo de una máquina de estado finito. Muy bien, dicho esto, intentemos comenzar a pensar en cómo podemos pensar en máquinas de estado con eso.

Muy bien, con ese ejemplo en mente, vamos a ver principalmente que, bueno, básicamente hay cuatro tipos con los que una interfaz de usuario puede existir. Puede estar inactiva o puedo hacer clic en el botón para que mi interfaz de usuario entre en un estado de carga que indique, bueno, se está iniciando sesión. Y si inicio sesión correctamente, voy a un estado de éxito o a un estado de error. Y eso es lo que define nuestras transiciones. Definimos que, bueno, cuál es el estado actual y, en función de eso, cuáles son las transiciones a las que ese estado puede ir y cuál es el siguiente estado. Y básicamente, dicho esto, tienes un estado, tienes una acción. Por ejemplo, si estoy en un estado inactivo, realizo una acción llamada submitForm y luego voy a un estado llamado isLoading. Y así es como visualizas las cosas y cómo creas un modelo mental de máquinas de estado en tu mente.

Entonces, si ves una correspondencia entre tu visualización y el código, básicamente en el lado derecho ves dos objetos simples donde un objeto state define cuáles son estos círculos a la izquierda, que son los estados que tienes. Y este objeto transitions simplemente te permite saber que, bueno, si estoy en un estado, digamos, states.idle, y realizo una acción llamada submitForm, voy a un estado llamado states.loading. Así que eso hace que tu interfaz de usuario sea más predecible y que toda esta lógica esté en un solo lugar. Y obviamente, dado que tenemos este cerebro listo, tenemos que decirle a este cerebro cómo comunicarse entre sus otros estados, ¿verdad? Entonces, esta es una función llamada transition. Y lo que hace es, básicamente, sabe cuál es el estado actual, cuál es la acción, y en función de eso, a qué estado siguiente tengo que ir. Y este cerebro y el cuerpo que se configuran en esta máquina, solo tienes una función simple justo debajo, que es updateForm state, donde no haces nada más que dejar que transition te diga cuál es el siguiente estado. Y simplemente establezco mi estado en función de eso.

Muy bien, dicho esto, creo que estás aburrido de todas estas teorías.

Entonces, intentemos adentrarnos, ¿cuál es la acción real? Muy bien, este es el ejemplo simple de este formulario. Y ahora esto se ha implementado con ese enfoque de detalles de implementación que teníamos en mente, ¿verdad? Entonces, permíteme traer ese código de plantilla, ¿verdad? Ya lo tengo escrito aquí. Así que permíteme copiar esto dentro de mi función. Vamos a tenerlo aquí mismo. Muy bien, permíteme descomentar esto. De acuerdo, estamos listos. Y ahora no necesito todos estos estados porque tengo esta máquina en su lugar.

De acuerdo, ahora hagamos algunas acciones con nuestras transiciones. De acuerdo, cuando estamos cargando esto, en su lugar podemos hacer, de acuerdo, actualizar el estado del formulario. Muy bien, y hacemos submit form. Así que ahora pasamos de un estado a otro. Si todo es un éxito, actualizamos el estado del formulario. Muy bien, entonces, formulario, o, creo que submit form, éxito, así que, como, realizamos esta acción para pasar al siguiente estado. De lo contrario, si nada sale bien y no puedo iniciar sesión, simplemente hago submit, o, submit, form, error. Muy bien, y en base a esto, mientras tenemos estas transiciones en su lugar, actualicemos cómo estamos representando la interfaz de usuario. De acuerdo, cómo llega este éxito es si el estado actual es igual, es éxito, y si el estado actual que hemos estado rastreando es estado.isError. Eso significa que, si obtenemos el error y nuestra máquina de estados está en ese estado de error, simplemente mostramos ese mismo mensaje. Y hablando de un botón deshabilitado, solo diré, de acuerdo, el estado actual es estado.isError. Y eso es principalmente todo, y esos son la mayoría de los factores que necesitas, ¿verdad? Vamos a actualizar rápidamente, y sí. Vamos a ver rápidamente si eso resulta bien. Entonces, tal vez ingreso un nombre de usuario, o ingreso una contraseña. Intento iniciar sesión. Y sí, eso funciona. Sí, el error es ficticio, pero esta parte funciona. Y esa es la belleza de una máquina de estado de React, ¿verdad? Porque toda tu lógica está ahora en un solo lugar. Y este es el único lugar al que quieres ir cuando estás leyendo este código, ¿verdad? ¿Y qué tan increíble es eso? De acuerdo. Con eso en mente, intentemos ver qué logros hemos obtenido. Obviamente, sin acceso a la esperanza, porque ahora has unificado el alma de tu aplicación en una sola pieza y no distribuida. Obviamente, es fácil debug, porque ahora tienes una visualización en mente, y ahora puedes ver, okay, si mi formulario no se comporta bien, hay algo que he hecho mal o algo que no he creado dentro de mi máquina de estados.

Así que ya sabes, como dónde buscar un error, o dónde buscar algo que no sea todo este código. Y obviamente, sin explosiones de estados, porque en lugar de tres, ahora solo tienes un estado único, y eso ha sido orquestado todo a través de una máquina de estado.

Ahora, otra cosa que ya teníamos como un problema eran las condiciones de carrera, donde intentas realizar algunas tareas asíncronas, y hay varias de ellas alineadas, y no sabes en qué orden pueden ocurrir. Y ahí radica la belleza de las máquinas de estado y cómo pueden ayudarte, ¿verdad? En un momento dado, tu interfaz de usuario solo puede estar en un estado y no en muchos estados paralelos. Entonces, si has definido bien tus máquinas de estado, no tendrás problemas con las condiciones de carrera. Así que eso se maneja de manera elegante.

Otra cosa muy importante que he sentido es la colaboración entre diseñadores y desarrolladores, porque siento que la mayoría de los diseñadores tienen un modelo mental de pensar en máquinas de estado. Entonces, la próxima vez, si vas a colaborar con los diseñadores, sabrás qué buscar o qué preguntarles y cuáles son las condiciones o situaciones de una interfaz de usuario donde necesitarías una aportación de un diseñador. Así que conoces las máquinas de estado, conoces las formas más posibles en las que tu interfaz de usuario puede comportarse. Y así es como realmente trabaja un diseñador. Así que eso hace que el proceso sea más eficiente.

Y también puede que estés pensando, `oye, ahora tengo este poder de las máquinas de estado, así que déjame ir a mi base de código y cambiar todo con máquinas de estado`. Y no recomendaría eso. Más bien diría que si hay una necesidad de una máquina de estado que podría surgir principalmente si tu código o si tu componente es muy complejo y hay una necesidad de visualizarlo en términos de su lógica. Y eso ha sido muy bien dicho por David Kushnick en uno de sus tweets y realmente creo en lo que mencionó que si la interfaz de usuario se visualiza y esa interfaz de usuario tiene un alma o una lógica en su interior que debe ser visualizada, entonces definitivamente debemos trabajar con las máquinas de estado porque nuestro objetivo principal es hacer que nuestro código sea legible y mantenible y no aplicar máquinas de estado por encima de eso. Así que, sí, diría que tengas eso en cuenta para evitar grandes días intentando actualizar todo a máquinas de estado.

Solo como una nota al margen, aquí están los enlaces útiles que podrías necesitar. Aquí está el enlace al manual del curso que te he estado mostrando en la demo y también el enlace a las diapositivas. Así que puedes encontrar todo eso aquí.

Por último, pero no menos importante, me gustaría mencionar que pruebes esta biblioteca llamada XState si te gustaría adentrarte en esta magia de las máquinas de estado. Es una gran biblioteca, la he probado y personalmente la recomiendo a todos aquellos que quieran agregar máquinas de estado a su proyecto. Te ayuda a agregar código minimalista y evitar todo ese código innecesario y repetitivo que hemos agregado en nuestra demostración. Así que pruébalo, creo que realmente te encantará. Así que felicitaciones a David por esto.

Como una nota al margen, nuevamente, estamos contratando en Postman. Sería genial ser parte de un viaje de construcción del producto. Ven a saludar y puedes contactarnos a través de nuestro sitio web de carreras.

Eso es todo lo que tenía para esta presentación. Un gran agradecimiento a React Advanced London, a las personas que participaron en la organización de esto y lo convirtieron en un gran éxito. Así que felicitaciones a ustedes chicos. Y por último, pero no menos importante, ustedes, el público, gracias por recibirme. Me encanta tener esta charla y discutir cosas. Nos vemos la próxima vez, me despido. Gracias.