Configuración de Máquina de Estados: Crear y Gestionar Vistas y Pasos

Clase 24 de 31Curso de React Avanzado

Contenido del curso

Patrones de renderizado y composición

Manejo del estado en React

Resumen

Construir un formulario tipo wizard con múltiples pasos requiere una estructura clara que controle qué se muestra, cuándo se puede avanzar y cómo se valida cada paso. Aquí se aborda exactamente eso: la configuración completa de una máquina de estados usando React y TypeScript, definiendo pasos, bloqueadores y vistas de forma declarativa.

¿Cómo se estructura el objeto de configuración de la máquina de estados?

Partiendo de una interfaz StateMachineConfig creada previamente, se construye un objeto que concentra toda la lógica del wizard en un solo lugar. Este objeto contiene tres propiedades fundamentales [0:10]:

  • initialStep: define desde qué paso arranca el formulario. En este caso, se establece como step1.
  • steps: cada paso tiene una key y un blocker, una función que determina si el usuario puede avanzar o debe permanecer en el paso actual.
  • views: asocia cada key con un componente visual que se renderiza cuando el usuario está en ese paso.

El initialStep es simplemente un string que coincide con una de las keys registradas en los pasos. Esto permite cambiar el punto de entrada del formulario sin modificar la lógica interna [0:30].

¿Qué son los blockers y cómo controlan la navegación?

Cada paso dentro de steps recibe una función llamada blocker. Esta función evalúa el estado actual y retorna un booleano que indica si el usuario puede avanzar [0:55].

Para el paso uno, el blocker valida que exista un nombre en el estado. Se toma state.name y se convierte a booleano con la doble negación implícita, de manera que si el string está vacío retorna false y bloquea el avance. Para el paso dos, la validación se aplica sobre state.age.

El paso de confirmación tiene un caso especial: su blocker retorna true siempre, porque es el último paso del wizard y no necesita validación adicional [1:30].

¿Cómo se definen las vistas para cada paso del wizard?

Las views son funciones que reciben state y setState como parámetros y retornan el JSX correspondiente [2:05].

Vista del paso uno — renderiza un div con un input cuyo value se enlaza a state.name. El evento onChange captura el texto ingresado y actualiza el estado usando el patrón de spread operator:

tsx setState((prev) => ({ ...prev, name: e.target.value, }));

Este patrón garantiza que al modificar el nombre no se pierdan los demás valores del estado, como la edad que podría haberse ingresado previamente. Se agrega también un placeholder con el texto fullname [2:40].

Vista del paso dos — replica la misma estructura pero con validaciones numéricas. El value apunta a state.age y en el onChange se utiliza parseInt para convertir el valor del input a entero antes de guardarlo en el estado [3:45].

Vista de confirmación — solo necesita lectura del estado, sin setState. Renderiza un párrafo que muestra el nombre y la edad ingresados:

tsx confirmation: (state) => (

<p>{state.name} is {state.age} years old</p> )

¿Cómo se tipan correctamente la configuración y sus parámetros?

TypeScript señala errores cuando las funciones de las vistas no tienen tipos definidos para state y prev. La solución es tipar el objeto de configuración directamente con la interfaz StateMachineConfig, pasándole dos genéricos [4:20]:

  • WizardState: el tipo del estado de la aplicación, que contiene name y age.
  • Los nombres de los steps como unión de strings literales.

Con esta asignación de tipos, TypeScript infiere automáticamente los parámetros de cada función dentro de views y steps, eliminando los errores y asegurando consistencia entre las keys de los pasos y las vistas [4:50].

¿Qué queda pendiente para completar la máquina de estados?

La configuración está lista con sus tres componentes: pasos con blockers, vistas con renderizado condicional y tipado estricto. El siguiente paso es construir la lógica de navegación dentro del componente principal para moverse entre los diferentes pasos utilizando esta máquina de estados.

¿Has implementado patrones similares para formularios multi-paso? Comparte tu enfoque en los comentarios.