Convirtiéndose en un Form Wizard: Flujos de Trabajo Intuitivos de Múltiples Pasos

Bienvenidos a Becoming a Form Wizard, una charla sobre la construcción de flujos de trabajo intuitivos y de múltiples pasos impulsados por máquinas de estados.

Mi nombre es Nick Hare, soy ingeniero de software en el equipo de plataforma front end en Betterment en la ciudad de Nueva York. En el pasado he ayudado a organizar eventos y meetups como Manhattan JS y ahora organizo una serie de charlas internas en Betterment llamada Better Dev. En mi tiempo libre, me gusta experimentar con JavaScript embebido, también soy fanático del ciclismo al aire libre y de la escalada en interiores. Puedes encontrarme en línea en hipsterbrown.com o como hipsterbrown en Twitter y GitHub.

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

Los wizards 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 múltiples pasos para enviar toda la información. Este patrón de interfaz de usuario se llama a menudo un wizard, un término que data de finales de los 80 y principios de los 90, para indicar guías paso a paso que están diseñadas para llevarte a través de una tarea compleja.

Una fuente popular de esta fraseología es la función de wizard de Microsoft Page Publisher y el Connection wizard. Sin embargo, el nombre generalmente me recuerda a este wizard. Muchos servicios y aplicaciones dividirán el proceso de registro en una serie de pasos para hacer que esto se sienta más fácil, especialmente si hay bastante información que recopilar para comenzar. Completar formularios largos puede ser increíblemente tedioso, por lo que los wizards proporcionan una experiencia donde las personas pueden centrarse en las piezas individuales de esos formularios con una sensación de logro con cada paso adelante. Basado en las elecciones hechas a través de este proceso, el wizard puede incluso ayudar a las personas a omitir caminos irrelevantes y potencial confusión.

Creo que hemos visto esas secciones en los formularios de impuestos con un montón de condiciones en letra pequeña que eventualmente llevan a ignorarlo por completo. Esto es lo que queremos evitar. Esto puede ser abrumador, distraer, e incluso, como dije antes, muy tedioso de pasar por. Esto es lo que queremos ver en su lugar. En Betterment, llamamos a este patrón un flujo o workflow 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 cuántos hemos tenido que construir y mantener, tiene sentido tener algunas convenciones comunes y utilidades para que nuestros equipos las usen.

Entonces, ¿cómo se construyen típicamente? Si alguna vez has tenido que abordar este patrón en el pasado, podrías haber buscado formularios multistep o un wizard de formularios para X, donde X es el framework de elección para tu producto. Sé que definitivamente busqué una solución así al comenzar este viaje en Betterment.

Naturalmente, miré la documentación y ejemplos de Formic, el gestor de estado de formularios de elección para React en Betterment. Mirando el repositorio de Formic, podemos encontrar un ejemplo de un wizard multistep que crea un componente wizard abstracto con componentes hijo de pasos de wizard. Esto permite una buena composición al dividir un formulario grande, y podría reutilizarse a través de características siempre que usen el mismo diseño. Una desventaja notable es la falta de enrutamiento. Así que el paso actual en el flujo se pierde si la página se recarga.

Y podemos ver nuestro componente wizard de nivel superior aquí, donde tenemos un array de pasos, y tenemos algunas acciones de siguiente y anterior para movernos a través del wizard. Tenemos nuestro manejador de envío, que permitirá que este paso declare su propio envío, y avanzaremos al siguiente paso a menos que estemos en el último paso, en cuyo caso realizamos un envío final. Y todo se recoge bajo un único contexto de formato con pasos individuales mostrados y nuestros botones de retroceso y envío realizando ya sea las acciones anteriores o siguientes. Y luego, como dije antes, todo se compondrá bajo el único wizard, pasos de wizard, y luego cada paso declarando los campos en los que se recopilan los valores que les importan.

Ahora, en el mismo repositorio, podemos encontrar ejemplos de formularios multistep con enrutamiento, uno usando pasos numerados y el otro usando pasos nombrados. Los pasos numerados proporcionan un beneficio de composición más simple como 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 nombrados, se pierde la capacidad de personalizar la validación y el envío del formulario por paso. Así que podemos ver aquí ubicaciones de ruta específicas para cada página. Todavía tenemos una base de wizard 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, algo de validación, manejar el envío, lo que nos hace avanzar al siguiente. Y luego tenemos algo de 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 compuesto bajo una única ruta con un wizard y sus páginas de wizard individuales, recopilando todos los campos en los que les importa. Y podemos ver nuestras páginas nombradas aquí, que tienen componentes de página individuales, que ahora enlazan al siguiente o incluso al paso anterior dentro del wizard, todo recopilado como rutas individuales bajo el enrutador de alto nivel alrededor de un único formulario.

La mayor debilidad de cada uno de estos ejemplos es lo vinculados que están a FormRec, lo cual en última instancia tiene sentido ya que estos son ejemplos para esta biblioteca. Sin embargo, muchos enfoques encontrados en línea promoverán patrones similares, especialmente con pasos sin enrutamiento. Todos están generalmente enfocados en moverse secuencialmente o en el orden en que se declaran. No es fácil ver cómo se pueden integrar rutas condicionales. Mirando las bibliotecas construidas para este propósito, nada parecía resolver todas las preocupaciones de construir flujos en Betterment, así que fue cuando decidí resolverlo yo mismo. Para ayudar a dirigir el trabajo hacia la construcción de esta nueva solución, se me ocurrieron tres directrices principales. La primera mantiene la idea de que las buenas experiencias web tienen URLs y se alinean con los flujos impulsados por Rails existentes que construimos en el pasado. La segunda fue aprender de los flujos existentes que los hicieron complejos de mantener en general. La última provino de observar nuestras necesidades en Betterment, y cómo los wizards pueden recopilar información pero no siempre es requerida por paso. Así que esta es la Dream API que vamos a implementar. Se parece mucho a lo que vimos antes con los ejemplos de Formic, donde tenemos un wizard 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 estar sin nombre en absoluto.

Y vamos a usar este conjunto de herramientas para hacerlo. Tenemos nuestro React context para usar un reducer hook de React, componentes de ruta de React Router, y un hook personalizado para unirlo todo.

Así que comenzaremos con nuestro React context para recopilar toda la información que necesitamos compartir entre el wizard de alto nivel y los pasos individuales. En nuestro componente wizard, vamos a iterar sobre los hijos para capturar aquellos que coincidan con nuestro componente de paso que construiremos, y buscar la prop name 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 reducer.

El wizard reducer lo veremos a continuación, pero estamos estableciendo el estado inicial al paso actual como el primer paso en el flujo. Los valores iniciales para ayudar a sembrar cualquier dato inicial que estemos recopilando en el flujo, y esa lista de pasos también. Y el valor devuelto por user reducer se establecerá como el proveedor de contexto del wizard. Vamos a mostrar todos los hijos pasados a través de nuestro componente wizard, y luego redirigir inicialmente desde el índice de esta característica al paso predeterminado. Así que cualquier cosa que dirija o enlace a esta característica no tiene que saber cuál es el primer paso.

Ahora nuestro wizard reducer es bastante simple como suelen ser los reducers. Tenemos dos acciones que contienen el sync para actualizar nuestro paso actual, y luego actualizar valores en los que, como sugiere el nombre, actualizar los valores que estamos recopilando a lo largo de la vida de nuestro wizard. Y aquí está el componente de paso al que nos referíamos antes. Así que tenemos nuestra prop component y nuestro name, y luego vamos a incorporar nuestro use wizard context hook, declararemos next para extender este estado como props en nuestros componentes. Esto es similar a otras APIs que ReactRouter solía usar en el pasado, y vamos a mapear el nombre de nuestro paso como la ruta de nuestro camino. Y veremos lo útil que puede ser tener el estado mapeado a props en nuestro componente a continuación.

Así que en nuestro hook de contexto del wizard, vamos a nuevamente, incorporar ese contexto usando el hook use context de React. Y como resultado de useReducer, vamos a obtener el estado del wizard y esa función de dispatch para enviar acciones a nuestro reducer. Vamos a envolver estas acciones de dispatch en nuestras propias funciones personalizadas solo para hacer más fácil para cualquier cosa que consuma este hook llamarlas. Así que tenemos nuestra acción sync, nuestra acción updateValues, y luego tenemos algo llamado goToStep, que usará ambos para llamar a updateValues si los tenemos, y luego llamar a sync, y luego avanzar en la historia, o simplemente avanzar y navegar al siguiente paso o paso anterior dependiendo de cómo se use. Y así nuestro siguiente paso buscará asegurarse de que no estamos en el último paso en nuestro en el wizard, y luego llamar a goToStep si no lo estamos. frente al paso anterior, que se asegurará de que no estamos en el primer paso y permitirá que llamemos a previous, si ese es el caso, y luego lo devolveremos todo como resultado de nuestro hook.

Y así aquí está esa API nuevamente, echemos un vistazo a cómo un paso individual puede componer esto. Como declaramos como parte de una de nuestras directrices, que puede ser independiente del formulario. Y así tenemos goToNextStep, goToPreviousStep, y wizard.state todo proveniente de ese hook el componente de paso en sí. Pero nuevamente, podríamos usar ese hook si quisiéramos directamente. Esto limpia un poco el código repetitivo y tener que siempre incorporar ese hook y permite un poco de inyección de dependencias en caso de que quieras probar esto individualmente más tarde. Y así nuestra función handleSubmit solo usa un formulario regular. Y vamos a capturar todos los valores del formulario del formulario HTML usando la nueva API de form date y este método object from entries, y luego llamar a goToNextStep con ese objeto a valores. Incluso podemos usar valores existentes del estado del wizard para establecer el valor predeterminado en nuestra entrada, y luego acciones de aspecto muy familiar, como nuestro botón previous y submit para ir hacia atrás o hacia adelante.

Si queremos limpiar parte del código repetitivo, podemos usar formic. Y nuestro goToNextStep se asigna exactamente a la prop onSubmit para formic, y nuestros valores del estado del wizard son solo un objeto, por lo que podemos usarlos para ver los valores iniciales para formic. Y luego tenemos nuestro field, que heredará automáticamente y se vinculará a ese valor de primer nombre dentro de los valores del estado del wizard. Y las acciones pueden permanecer iguales, porque son solo un botón y un manejador de envío. Y no se necesita ningún formulario en absoluto, porque si solo queremos mostrar el estado del wizard, 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 paso individuales, sino a este nivel alto. Entonces, ¿qué sucede cuando mostrar un paso o conjunto de pasos depende de una elección hecha en una parte anterior de nuestro wizard? ¿Y cómo nos ayudan las máquinas de estados a resolver este problema?

Para aquellos que no están familiarizados con las máquinas de estados, se conocen formalmente como autómatas de estados finitos. Proporcionan un modelo matemático de computación que describe el comportamiento de un sistema que solo puede mostrar un estado en un momento dado. La capacidad de transitar entre estos estados está determinada por eventos específicos. Ahora, si quisiéramos relacionar eso directamente con un wizard, podemos decir que un wizard es una experiencia interactiva que puede mostrar exactamente uno de un número finito de pasos en un momento dado. El wizard 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 wizard se define por una lista de pasos, su paso inicial y las condiciones para cada navegación. Podemos usar esta idea de modelar nuestros wizards como máquinas de estados en forma de diagramas de estados.

Entonces, este diagrama de estados se construye usando Text y MermaidJS para generar la visualización. Y así podemos ver nuestros estados individuales, o pasos, inicio, sobre y completar. Pueden realizar transiciones o navegaciones usando siguiente o anterior para avanzar o retroceder. Y esto nos permite incluso usar cosas como el visualizador de AI stately para visualizar esto de una manera de arrastrar y soltar o incluso basada en código. Como dije antes, podemos controlar las condiciones de cada navegación. Entonces, mirando una versión modificada de ese diagrama que vimos antes, podemos ver que inicio recibe un evento siguiente y luego puede progresar a Gandalf o Merlin según lo que se conoce como un guard. Y así, este guard mira alguna lógica para ver si tenemos interés en Gandalf para progresar allí, o de lo contrario retroceder a Merlin. Y cada uno de esos pasos progresará siguiente a completar. Y aquí está de nuevo usando el visualizador de AI stately para darnos otro punto de vista y vemos ese guard declarado en ese siguiente a Gandalf. Y esto siempre me hace pensar en cómo Gandalf ayudará a proteger el camino para el viaje a donde sea que vayan. Y así podemos crear esto dentro de nuestra abstracción de wizard usando una función que toma los valores actuales del wizard y cualquier estado siguiente pasado para ir al siguiente paso. Y mirando los valores en el siguiente estado, si tenemos interés en Gandalf, entonces devolverá verdadero. Podemos declarar la lista de pasos siguientes disponibles en nuestro componente de inicio, sobrescribiendo el comportamiento predeterminado de ir en secuencia en la que están declarados. Y así, en ese array, también podemos declarar otro array como la tupla de lógica. Y así tenemos nuestro Gandalf, cuando, e iremos allí cuando estemos interesados en Gandalf. De lo contrario, retrocederemos al paso de Merlin. Y en los pasos individuales de Merlin y Gandalf, podemos sobrescribir ese comportamiento predeterminado de siguiente y anterior simplemente declarando a dónde queremos ir a continuación sin ningún tipo de condiciones. Y puedes ver un patrón similar siendo usado por Cassidy Williams en su masterclass, eligiendo tus propias aventuras en Next.js, donde usa XState para hacer un viaje similar a través de Next.js. Así que pasamos por construir nuestro Wizard usando solo React y un conjunto de otras utilidades dentro de allí, pero no vimos cómo podemos integrar una máquina de estados 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 estados. Como acabamos de ver aquí, no depende de nada que ver con React o cualquier framework específico o formulario. Así que puedes traer tu propio gestor de UI y formularios incluso si es solo HTML. Y estamos usando XState FSM, que es un subconjunto del paquete más amplio XState, para impulsar todo esto debajo de una API intuitiva.

Y así, esto fue originalmente inspirado por un paquete llamado Robot, que nos permitió impulsar todo esto usando composición funcional. Sin embargo, eventualmente lo cambié a usar XState FSM para acceder a la comunidad más amplia de XState y el visualizador y todas las APIs que proporciona. RoboWizard, en su núcleo, se ve así. Tenemos una función createWizard, que toma una lista de pasos, y luego cualquier valor inicial que queramos recopilar a lo largo de la vida de ese wizard. Y cuando comenzamos el wizard, podemos listar 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, incluyendo este paquete principal que vemos aquí, la integración de RoboWizard React y la integración de RoboWizard React Router para esos pasos navegables enrutados. Sin embargo, hay un puñado de proyectos de ejemplo dentro del repositorio para mostrar cómo RoboWizard puede integrarse en Vue, Svelte, Alpine, y nuevamente, HTML simple.

Así que, ¿por qué no echamos un vistazo a cómo se ve crear esta máquina usando la configuración de la máquina XState por ti mismo? Si quisieras recrear principalmente RoboWizard, así es como lo harías. Esa línea en el ejemplo previo 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 estados individuales, qué eventos desencadenarán ir al siguiente estado o paso y las acciones que tomamos en ese evento y transición. Podemos ver aquí, puedes ir al siguiente a about, y actualizaremos los valores a lo largo de eso. Anterior desde about volverá a start, y así sucesivamente. Veamos un ejemplo práctico de RoboWizard en el navegador. Esta es la integración de RoboWizard React router usando el demo de code sandbox. Vamos a recopilar algunos valores de registro para email, contraseña, nombre, apellido, número de teléfono y acuerdos de términos. Estamos usando chakra UI React para proporcionar un poco de UI agradable a través de este demo. Y podemos ver nuestros componentes de paso y wizard siendo extraídos de nuestro paquete compartido. Y vamos a establecer algunos valores iniciales y declarar nuestra lista de pasos, todos yendo en orden y sin sobrescribir ninguno de los comportamientos iniciales. Si miramos un paso individual como nuestro email, podemos ver que estamos extrayendo el hook use wizard contact, muy familiar a lo que construimos antes. Y en ese wizard, podemos obtener valores actuales para valores iniciales y nuestro manejador de envío, vamos a llamar a go to next step con un campo de valores llamado values. Y vemos que todavía estamos usando los componentes de campo regulares y un botón de envío, cualquier cosa que quiera ir hacia atrás.

Podemos configurar un botón de retroceso hacia atrás. Y así, al mirar para enviar esto, vamos a crear algunos valores iniciales aquí. Y así hemos avanzado hacia adelante en el envío, puedo volver usando este botón de retroceso, puedo continuar hacia adelante, también puedo usar los botones de retroceso y avance del navegador para llevar un registro de nuestro historial.

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

Ahora, si volvemos, podemos ver si no mantenemos nuestros valores de estar de acuerdo con los términos, podemos aún continuar hacia adelante. Ahora, ¿qué pasa si quisiéramos enviarlos en una dirección completamente diferente si no están de acuerdo con el acuerdo de usuario? Bueno, hagamos eso sin tocar ninguna de la lógica en los pasos individuales. Así que voy a ir aquí y hacer una demostración mágica. Voy a cambiar algunos de los pasos aquí para ahorrarnos algo de tiempo. Y voy a usar unos componentes de borrador precreados y luego también tomar mi función de guardia. Y esta función de guardia mira si los próximos valores están siendo pasados y luego busca. Si estamos de acuerdo con los términos siendo muy explícitos al respecto, podríamos simplemente devolver el booleano que existe allí. Y luego vamos a traer nuestro ayudante de guardia when de Robo Wizard . Así que vamos a pasar por esto de nuevo sin cambiar ninguno de los pasos existentes, solo permaneciendo en este nivel alto. Así que doff dot gray. Elige algo súper seguro. Solo voy a acortar esto un poco. Y luego si no estamos de acuerdo con nuestro lorem ipsum continuamos hacia adelante y oh, no. Drat, el viaje termina aquí. ¿Así que deberíamos intentarlo de nuevo? Volver y continuar. Y ahora hemos enviado con éxito y nos hemos convertido en un forum wizard. ¿Y entonces a dónde vamos desde aquí? Bueno, el viaje de un wizard nunca termina. Así que, ¿cómo podemos comunicarnos mejor sobre los wizards o comunicarnos sobre los wizards mejor mientras podemos aprender a visualizar todo este comportamiento del wizard usando herramientas como los mermaid jest diagrams o incluso el visualizador de stately AI. Y podemos construir sobre eso para crear un lenguaje compartido que todas las personas que participan en la construcción de estas características exitosas puedan entender diseño de producto diseño y ingeniería. Y podemos agregar cosas como pasos de entrada y salida, que nos permiten definir dónde podemos entrar en el flujo o el wizard y dónde, cómo podemos salir. Así que cosas como redirecciones no existen dentro de los pasos individuales. Pero nuevamente, en ese nivel superior, podemos definir pasos finales, que nos permiten pausar o prevenir cualquier otra navegación desde ese paso, lo que significa que no puedes volver atrás de nuevo, o nunca puedes avanzar en el caso de éxito o donde no quieres reenviar algún tipo de acción, o en el caso de errores irrecuperables donde necesitan reiniciar para intentarlo de nuevo. Podemos crear flujos ramificados o servicios anidados en el caso de algo como XState, que nos permite elegir un desvío en el camino e ir a un final completamente diferente que cuando cualquier otra condición lo haría. Y también podemos activar transiciones impulsadas por el servidor. Así que antes vimos cómo esto se integraba con el 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 backend de servidor general. Ni siquiera tiene que hacerse con JavaScript. Sin embargo, XState hace que esto sea mucho más fácil de hacer en conjunto. Y si todo esto te suena 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 encontrar más en robowizard.js.org o en HapsAround en Twitter.