Convirtiéndose en un Maestro de Formularios: Flujos de Trabajo Intuitivos de Múltiples Pasos

Bienvenido a Convertirse en un Asistente de Formularios, una charla sobre la construcción de flujos de trabajo intuitivos y de múltiples pasos impulsados por máquinas de estado.

Mi nombre es Nick Hare, soy un ingeniero de software senior en el equipo de plataforma de front-end en Betterment en la ciudad de Nueva York. En el pasado, he ayudado a organizar eventos y encuentros como Manhattan JS y ahora organizo una serie de charlas internas en Betterment llamada Better Dev. Además, me gusta experimentar con JavaScript integrado y soy fanático de andar en bicicleta al aire libre y escalar en interiores. Puedes encontrarme en línea en hipsterbrown.com o en hipsterbrown en Twitter y GitHub.

En nuestro viaje de hoy aprenderemos todo sobre qué es un asistente, cómo se crean típicamente, cómo las máquinas de estado pueden ayudarnos a mejorarlos, qué podemos usar para implementarlos y hacia dónde vamos desde aquí.

Los asistentes han existido durante muchos años. Al construir aplicaciones, solicitar la entrada del usuario para crear registros o realizar acciones no siempre es tan simple como un formulario en una sola página. Muchas experiencias de usuario requieren que los clientes hagan clic a través de varios pasos para enviar toda la información. Este patrón de interfaz de usuario a menudo se llama asistente, un término que se remonta a finales de los años 80 y principios de los 90, para indicar guías paso a paso diseñadas para ayudarlo a realizar una tarea compleja.

Una fuente popular de esta fraseología es la función de asistente de Microsoft Page Publisher y el asistente de conexión. Sin embargo, el nombre generalmente me recuerda a este asistente. Muchos servicios y aplicaciones dividen el proceso de registro en una serie de pasos para que sea más fácil, especialmente si hay mucha información que recopilar para comenzar. Rellenar formularios largos puede ser increíblemente tedioso, por lo que los asistentes brindan una experiencia en la que las personas pueden centrarse en las partes individuales de esos formularios con una sensación de logro en cada paso adelante. Según las elecciones realizadas en este proceso, el asistente incluso puede ayudar a las personas a omitir rutas irrelevantes y posibles confusiones.

Creo que todos hemos visto esas secciones en los formularios de impuestos con un montón de condicionales en letra pequeña que al final terminamos ignorando por completo. Eso es lo que queremos evitar. Puede ser abrumador, distraído e incluso, como dije antes, muy tedioso de pasar. En su lugar, queremos ver esto. En Betterment, llamamos a este patrón flujo o flujo de trabajo y lo usamos bastante. Como empresa de servicios financieros, hay mucha información y conceptos complejos que cubrir. Queremos asegurarnos de que nuestros clientes comprendan estas decisiones. Junto con las tareas habituales de registro, formalizamos la creación de metas, mover dinero, conectar cuentas externas y más, todo como flujos. Dado la cantidad que hemos tenido que construir y mantener, tiene sentido tener algunas convenciones y utilidades comunes para que nuestros equipos las utilicen.

Entonces, ¿cómo se construyen típicamente? Si alguna vez has tenido que abordar este patrón en el pasado, es posible que hayas buscado formularios de varios pasos o un asistente de formulario para X, donde X es el marco de elección para tu producto. Sé que definitivamente busqué una solución así cuando comencé este viaje en Betterment.

Naturalmente, busqué la documentación y ejemplos de Formic, el administrador de estado de formulario elegido para React en Betterment. Al mirar el repositorio de Formic, podemos encontrar un ejemplo de un asistente de varios pasos que crea un componente de asistente abstracto con componentes secundarios de paso de asistente. Esto permite una composición agradable al dividir un formulario grande, y se puede reutilizar en diferentes características siempre que utilicen el mismo diseño. Una desventaja notable es la falta de enrutamiento. Por lo tanto, el paso actual en el flujo se pierde si se recarga la página.

Podemos ver aquí nuestro componente de asistente de nivel superior, donde tenemos una matriz de pasos y tenemos algunas acciones de siguiente y anterior para avanzar en el asistente. Tenemos nuestro controlador de envío, que permite que este paso declare su propio envío, y avanzaremos al siguiente paso a menos que estemos en el último paso, en cuyo caso realizaremos un envío final. Todo se recopila bajo un contexto de formato único con pasos individuales mostrados y nuestros botones de retroceso y envío realizando acciones anteriores o siguientes. Y luego, como dije antes, todo se compone bajo el asistente único, pasos del asistente y luego cada paso declara los campos en los que se recopilan los valores que les importan.

Ahora, en el mismo repositorio, podemos encontrar ejemplos de formularios de múltiples pasos enrutados, uno utilizando pasos numerados y otro utilizando pasos con nombres. Los pasos numerados proporcionan un beneficio de composición más simple como en el primer ejemplo, aunque los números no son muy útiles como nombres de ruta para comunicar la intención del paso. Con los pasos con nombres, se pierde la capacidad de personalizar la validación y el envío del formulario por paso. Aquí podemos ver ubicaciones de ruta específicas para cada página. Todavía tenemos una base de asistente y ahora un componente de página asociado para pasar a través de los hijos en lugar de un componente de paso. Todavía tenemos nuestras acciones de siguiente y anterior, alguna validación, manejo de envío, que nos hace avanzar al siguiente. Y luego tenemos cierta lógica para mostrar nuestro contexto de Formic de alto nivel, nuestro formulario, la página activa y luego esa acción de retroceso y envío nuevamente, todo se compone bajo una sola ruta con un asistente y sus páginas de asistente individuales, recopilando todos los campos que les importan.

La mayor debilidad de cada uno de estos ejemplos es lo vinculados que están a Formic, lo cual tiene sentido ya que son ejemplos para esta biblioteca. Sin embargo, muchos enfoques que se encuentran en línea promoverán patrones similares, especialmente con pasos sin enrutamiento. Todos se centran en moverse secuencialmente o en el orden en que se declaran. No es fácil ver cómo se pueden integrar rutas condicionales. Al mirar las bibliotecas creadas específicamente, no parecía que resolvieran todas las preocupaciones de construir flujos en Betterment, así que decidí resolverlo yo mismo. Para dirigir el trabajo hacia la construcción de esta nueva solución, establecí tres directivas principales. La primera mantiene la idea de que las buenas experiencias web tienen URL y se alinean con los flujos impulsados por Rails que construimos en el pasado. La segunda fue aprender de flujos existentes que los hacían complejos de mantener en general. La última vino de observar nuestras necesidades en Betterment y cómo los asistentes pueden recopilar información pero no siempre es requerida en cada paso. Esta es la API Dream que vamos a implementar. Se parece mucho a lo que vimos antes con los ejemplos de Formic, donde tenemos un asistente de alto nivel y componentes de paso individuales que presentarán un conjunto de campos o lo que deseen hacer, y estos tienen nombres en lugar de números o sin nombre en absoluto.

Y vamos a utilizar este conjunto de suministros para hacerlo. Tenemos nuestro contexto de React para usar un gancho de reductor de React, componentes de ruta de React Router y un gancho personalizado para unirlo todo.

Comenzaremos con nuestro contexto de React para recopilar toda la información que necesitamos compartir entre el asistente de alto nivel y los pasos individuales. En nuestro componente de asistente, vamos a iterar sobre los hijos para obtener aquellos que coincidan con nuestro componente de paso que construiremos, y buscar la propiedad de nombre y recopilar nuestra lista de nombres como nuestros pasos. Vamos a establecer el paso predeterminado como el primero en esa lista, y luego declarar nuestro reductor.

El reductor del asistente lo veremos a continuación, pero estableceremos el estado inicial como el paso actual, el primer paso en el flujo. Los valores iniciales ayudarán a sembrar cualquier dato inicial que estemos recopilando en el flujo, y también esa lista de pasos. El valor devuelto por el reductor del usuario se establecerá como el proveedor del contexto del asistente. Mostraremos todos los hijos pasados a través de nuestro componente de asistente, y luego redirigiremos inicialmente desde el índice de esta función al paso predeterminado. Por lo tanto, cualquier dirección o enlace a esta función no tiene que saber cuál es el primer paso.

Ahora nuestro reductor del asistente es bastante simple en comparación con otros reductores. Tenemos dos acciones que contienen la sincronización para actualizar nuestro paso actual, y luego actualizar los valores para, como sugiere el nombre, actualizar los valores que estamos recopilando a lo largo de la vida útil de nuestro asistente. Y aquí está el componente de paso al que nos referíamos antes. Tenemos nuestra propiedad de componente y nuestro nombre, y luego vamos a utilizar nuestro gancho de contexto del asistente, que declararemos a continuación, para propagar este estado como propiedades en nuestros componentes. Esto es similar a otras API que ReactRouter solía usar en el pasado, y vamos a asignar el nombre de nuestro paso como la ruta de nuestra ruta. Y veremos lo útil que puede ser tener el mapa de estado a propiedades en nuestro componente a continuación. En nuestro gancho de contexto del asistente, vamos a volver a utilizar ese contexto utilizando el gancho de contexto de React. Y como resultado de useReducer, obtendremos el estado del asistente y esa función de despacho para enviar acciones a nuestro reductor. Vamos a envolver estas acciones de despacho en nuestras propias funciones personalizadas solo para facilitar la llamada a ellas para cualquier cosa que consuma este gancho. Tenemos nuestra acción de sincronización, nuestra acción de actualización de valores, y luego tenemos algo llamado goToStep, que utilizará ambas para llamar a updateValues si las tenemos, y luego llamar a sync, y luego avanzar en el historial, o simplemente avanzar y navegar al siguiente paso o al paso anterior dependiendo de cómo se use. Y así, nuestro siguiente paso buscará asegurarse de que no estemos en el último paso de nuestro asistente, y luego llamará a goToStep si no lo estamos, en comparación con el paso anterior, que se asegurará de que no estemos en el primer paso y nos permitirá llamar a previous, si ese es el caso, y luego lo devolveremos todo como resultado de nuestro gancho.

Y aquí está esa API nuevamente, veamos cómo un paso individual puede componer esto. Como declaramos como parte de una de nuestras directivas, puede ser independiente del formulario. Así que tenemos goToNextStep, goToPreviousStep y wizard.state que provienen de ese gancho, el componente de paso en sí. Pero nuevamente, podríamos usar ese gancho si quisiéramos directamente. Esto limpia un poco el código repetitivo y evita tener que llamar siempre a ese gancho, y permite una inyección de dependencia en caso de que quieras probar esto individualmente más tarde. Entonces, nuestra función handleSubmit simplemente utiliza un formulario regular. Vamos a obtener todos los valores del formulario del formulario HTML utilizando el nuevo método de objeto de fecha del formulario, y luego llamar a goToNextStep con ese objeto para los valores. Incluso podemos usar valores existentes del estado del asistente para establecer el valor predeterminado en nuestra entrada, y luego acciones muy familiares, como nuestro botón de retroceso y enviar para retroceder o avanzar.

Si queremos simplificar el código repetitivo, podemos usar Formic. Y nuestro goToNextStep se asigna exactamente a la propiedad onSubmit de Formic, y nuestro estado del asistente es solo un objeto, por lo que podemos usar eso para ver los valores iniciales de Formic. Y luego tenemos nuestro campo, que heredará automáticamente y se vinculará a ese valor del primer nombre dentro de los valores del estado del asistente. Y las acciones pueden seguir siendo las mismas, porque solo son un botón y un controlador de envío. Y no se necesita ningún formulario en absoluto, porque si solo queremos mostrar el estado del asistente, entonces podemos mostrarlo como queramos.

Ahora, la solución parece cubrir la mayoría de nuestros usos y necesidades. Sin embargo, todavía tenemos una forma de proporcionar condiciones sin tener que actualizar algo específico dentro de los componentes de cada paso, sino a este nivel superior. Entonces, ¿qué sucede cuando mostrar un paso o conjunto de pasos depende de una elección realizada en una parte anterior de nuestro asistente? ¿Y cómo nos ayudan las máquinas de estado a resolver este problema?

Para aquellos que no están familiarizados con las máquinas de estado, se conocen formalmente como autómatas finitos. Proporcionan un modelo matemático de computación que describe el comportamiento de un sistema que solo puede mostrar un estado a la vez. La capacidad de transición entre estos estados está determinada por eventos específicos. Ahora, si quisiéramos relacionarlo directamente con un asistente, podríamos decir que un asistente es una experiencia interactiva que puede mostrar exactamente uno de un número finito de pasos a la vez. El asistente puede cambiar de un paso a otro en respuesta a algunas entradas o eventos externos. El cambio de un paso a otro se llama navegación. Un asistente se define por una lista de pasos, su paso inicial y las condiciones para cada navegación. Podemos utilizar esta idea de modelar nuestros asistentes como máquinas de estado en forma de diagramas de estado.

Este diagrama de estado se construye utilizando Text y MermaidJS para generar la visualización. Podemos ver nuestros estados individuales, o pasos, inicio, acerca de y completar. Podemos realizar transiciones o navegaciones utilizando siguiente o anterior para avanzar o retroceder. Esto nos permite incluso utilizar cosas como el visualizador de IA estatal para visualizar esto de manera gráfica o incluso basada en código. Como dije antes, podemos controlar las condiciones de cada navegación. Al observar una versión modificada de ese diagrama que vimos antes, podemos ver que el inicio recibe un evento siguiente y luego puede avanzar hacia Gandalf o Merlin en función de lo que se conoce como un guardia. Y este guardia analiza alguna lógica para ver si tenemos interés en Gandalf para progresar allí, o de lo contrario, retrocedemos a Merlin. Y cada uno de esos pasos avanzará al siguiente hasta completar. Aquí está nuevamente utilizando el visualizador de IA estatal para darnos otro punto de vista y vemos ese guardia declarado en el siguiente a Gandalf. Esto siempre me hace pensar en cómo Gandalf ayudará a proteger el camino para el viaje a donde sea que vayan. Podemos crear esto dentro de nuestra abstracción de asistente utilizando una función que tome los valores actuales del asistente y cualquier estado siguiente pasado para ir al siguiente paso. Al observar los valores en el estado siguiente, si tenemos interés en Gandalf, entonces devolverá verdadero. Podemos declarar la lista de siguientes pasos disponibles en nuestro componente de inicio, anulando el comportamiento predeterminado de avanzar en secuencia en el que se declaran. Y así, en esa matriz, también podemos declarar otra matriz como la tupla de lógica. Y así tenemos a Gandalf, cuando, y avanzaremos allí cuando estemos interesados en Gandalf. De lo contrario, retrocederemos al paso de Merlin. Y en los pasos individuales de Merlin y Gandalf, podemos anular ese comportamiento predeterminado de siguiente y anterior simplemente declarando a dónde queremos ir a continuación sin ninguna condición. Se puede ver un patrón similar utilizado por Cassidy Williams en su charla, eligiendo tus propias aventuras en Next.js, donde utiliza XState para hacer un viaje similar a través de Next.js. Pasamos por la construcción de nuestro asistente utilizando solo React y un conjunto de otras utilidades dentro de él, pero no vimos cómo podemos integrar una máquina de estado dentro de ese patrón.

Bueno, para hacer todo eso más fácil, he creado una biblioteca llamada Robo Wizard. Y Robo Wizard se trata de construir flujos de trabajo intuitivos de varios pasos respaldados por una máquina de estado. Como acabamos de ver, no depende de nada relacionado con React o algún framework específico o formulario. Por lo tanto, puedes utilizar tu propia interfaz de usuario y administrador de formularios, incluso si es solo HTML. Y estamos utilizando XState FSM, que es un subconjunto del paquete XState más amplio, para alimentar todo esto debajo de una API intuitiva.

Esto fue inspirado originalmente por un paquete llamado Robot, que nos permitía alimentar todo esto utilizando composición funcional. Sin embargo, eventualmente lo cambié para utilizar XState FSM y así acceder a la comunidad más amplia de XState y al visualizador y todas las API que proporciona. RoboWizard, en su núcleo, se ve así. Tenemos una función createWizard, que recibe una lista de pasos y cualquier valor inicial que queramos recopilar a lo largo de la vida útil de ese asistente. Cuando iniciamos el asistente, podemos escuchar cualquier cambio en el paso y los valores actuales. Podemos llamar a goToNextStep, goToPreviousStep, todo familiar a lo que vimos antes. Y actualmente hay tres paquetes oficiales para RoboWizard, incluido este paquete principal que vemos aquí, la integración de RoboWizard con React y la integración de RoboWizard con React Router para esos pasos navegables enrutados. Sin embargo, hay varios proyectos de ejemplo dentro del repositorio que muestran cómo se puede integrar RoboWizard en Vue, Svelte, Alpine y nuevamente, en HTML básico.

Entonces, ¿por qué no echamos un vistazo a cómo se ve crear esta máquina utilizando la configuración de la máquina XState por ti mismo? Si quisieras recrear en su mayoría RoboWizard, así es como lo harías. Esa línea en el ejemplo de vista previa crea este objeto JSON completo. Tenemos nuestro objeto JavaScript, no solo JSON. Tenemos un paso inicial aquí. Tenemos nuestro contexto de los valores que estamos recopilando o los estados individuales, qué eventos desencadenarán el paso al siguiente estado o paso y las acciones que realizamos al recibir ese evento y transición. Podemos ver aquí que puedes ir al siguiente paso, que es 'about', y actualizaremos los valores a lo largo de eso. Anteriormente, desde 'about', volveremos al inicio, y así sucesivamente. Veamos un ejemplo práctico de RoboWizard en el navegador. Este es un ejemplo de integración de RoboWizard con React Router utilizando un demo en CodeSandbox. Vamos a recopilar algunos valores de registro para el correo electrónico, la contraseña, el nombre, el apellido, el número de teléfono y los acuerdos de términos. Estamos utilizando Chakra UI React para proporcionar una interfaz de usuario agradable a través de esta demostración. Y podemos ver nuestros componentes de paso y asistente que se extraen de nuestro paquete compartido. Y vamos a establecer algunos valores iniciales y declarar nuestra lista de pasos, todos en orden y sin anular ningún comportamiento inicial. Si observamos un paso individual como nuestro correo electrónico, podemos ver que estamos utilizando el gancho useWizardContext, muy familiar a lo que construimos antes. Y en ese asistente, podemos obtener los valores actuales para los valores iniciales y nuestro controlador de envío, vamos a llamar a goToNextStep con un campo de valores llamado 'values'. Y vemos que todavía estamos utilizando los componentes de campo regulares y un botón de envío, cualquier cosa que quiera retroceder.

Y así, dentro de este asistente, podemos registrarnos y convertirnos en un Robo Wizard. Así que completando un par de valores aquí, quién sabe por qué un mago podría necesitar un número de teléfono, podemos ver nuestros largos términos, lorem ipsum para continuar, presionaremos continuar y avanzaremos. Y aquí vemos, nos detuvimos, estamos al final, estamos en éxito, ahora nos hemos convertido en un mago del foro, podemos recibir cartas y alertas. Y luego obtener más información sobre esta magia en robowizardjs.org.

Ahora, si retrocedemos, podemos ver que si no mantenemos nuestros valores de acuerdo con los términos, podemos seguir avanzando. Ahora, ¿qué pasa si quisiéramos enviarlos en una dirección completamente diferente si no están de acuerdo con el acuerdo del usuario? Bueno, hagámoslo sin tocar la lógica en los pasos individuales en sí. Así que voy a hacer aquí una demostración mágica. Voy a cambiar algunos de los pasos aquí para ahorrarnos tiempo. Y voy a utilizar componentes de borrador pre-creados y también tomar mi función de guardia. Y esta función de guardia examina si los siguientes valores se están pasando y luego busca. Si estamos de acuerdo con los términos, siendo muy explícitos al respecto, simplemente podemos devolver el matón y eso existe allí. Y luego vamos a utilizar nuestro ayudante when guard de Robo Wizard . Y así vamos a pasar por esto de nuevo sin cambiar ninguno de los pasos existentes, simplemente quedándonos en este nivel alto. Haz algo súper seguro. Y luego, si no estamos de acuerdo con nuestro lorem ipsum, continuamos hacia adelante y oh, no. Drat, el viaje termina aquí. ¿Deberíamos intentarlo de nuevo? Retroceder y continuar. Y ahora hemos enviado con éxito y nos hemos convertido en un mago del foro. Y entonces, ¿a dónde vamos desde aquí? Bueno, el viaje de un mago nunca termina. Entonces, ¿cómo podemos comunicarnos mejor sobre los magos o comunicarnos sobre los magos de una mejor manera? Podemos aprender a visualizar todo este comportamiento del mago utilizando herramientas como los diagramas de mermaid jest o incluso el visualizador de stately AI. Y podemos construir sobre eso para crear un lenguaje compartido que todas las personas que participen en la construcción de estas características exitosas puedan entender el diseño del producto y la ingeniería. Y podemos agregar cosas como pasos de entrada y salida, que nos permiten definir dónde podemos ingresar al flujo o al asistente y dónde, cómo podemos salir. Por lo tanto, cosas como redireccionamientos no existen dentro de los pasos individuales en sí. Pero nuevamente, en ese nivel superior, podemos definir pasos finales, que nos permiten pausar o evitar cualquier otra navegación desde ese paso, lo que significa que no puedes retroceder nuevamente, o nunca puedes avanzar en el caso de éxito o cuando no quieres volver a enviar alguna acción, o en el caso de errores irreparables donde necesitan reiniciar para intentarlo de nuevo. Podemos crear flujos ramificados o servicios anidados en el caso de algo como XState, que nos permite tomar un camino diferente y llegar a un final completamente diferente que en cualquier otra condición. Y también podemos activar transiciones impulsadas por el servidor. Entonces, antes vimos cómo se integra esto con la navegación del lado del cliente y la navegación del lado del cliente, ¿qué pasa con algo impulsado por Next.js o Remix o incluso algún otro servidor general backend? Incluso no tiene que ser hecho con JavaScript. Sin embargo, XState hace que todo esto sea mucho más fácil de hacer en conjunto. Y si todo esto te parece interesante, puedes venir a ayudar. Todavía necesitamos ayuda con RoboWizard para construir, ya sabes, integraciones oficiales para todos esos otros frameworks que la gente quiere hacer, probar todos los diferentes casos de uso para esta biblioteca y aprender todo lo que podemos hacer para construir una mejor experiencia de esta manera. Y así, gracias y feliz construcción. Puedes obtener más información en robowizard.js.org o en HapsAround en Twitter. Gracias.