Trabajar con máquinas de estado en XState va más allá de definir nodos y transiciones. Necesitas entender qué información expone cada estado y qué métodos tienes disponibles para consultarlo. Aquí desglosamos las propiedades y métodos clave de los estados en XState, pensado para desarrolladores frontend que ya dieron sus primeros pasos con la librería y quieren manipular estados con precisión.

¿Qué propiedades expone un estado en XState?

Cada estado en XState es un objeto con varias propiedades que describen dónde estás, cómo llegaste y qué puedes hacer a continuación.

¿Qué es value y cómo cambia con máquinas anidadas?

La propiedad value te dice el nombre del estado actual. Si acabas de iniciar la máquina y estás en el estado initial, value retorna el string "initial".

Cuando tienes una máquina padre con una máquina hija anidada, este string se transforma en un objeto que indica el estado del padre y el del hijo simultáneamente. Esto se vuelve relevante en arquitecturas con jerarquías de estados.

¿Qué es el value en una máquina de estados? Es la propiedad que expone el nombre del estado actual. Retorna un string en máquinas simples y un objeto cuando hay estados anidados o paralelos.

¿Para qué sirve el context dentro de una máquina?

El context es la parte mutable del estado donde guardas información que cambia con el tiempo: variables, objetos, arrays. Si construyes una máquina contador, el context guardaría la variable contador y la irías incrementando en las transiciones que correspondan.

Es el lugar correcto para almacenar datos dinámicos sin contaminar la lógica de transiciones.

¿Qué información dan event, history y meta?

Estas tres propiedades te ayudan a rastrear el recorrido y agregar datos persistentes:

• event: nombre del evento que disparó la transición al estado actual. Si pasaste de initial a búsqueda con el evento Start, al imprimirlo desde búsqueda obtendrás Start.
• history: referencia al estado anterior. Útil cuando un mismo estado puede alcanzarse desde varios orígenes y necesitas saber de cuál vienes para validar.
• meta: sección de metadata permanente. Acepta strings, números o cualquier valor que quieras asociar al estado y que no cambie con transiciones.

¿Qué hacen actions, activities y nextEvents?

Estas propiedades describen ejecución y posibilidades futuras dentro del estado.

¿Cuál es la diferencia entre actions y activities?

Las actions son un array de funciones de ejecución única, tipo fire and forget. Entras al estado, se ejecutan y listo.

Las activities son tareas continuas mientras permaneces en el estado, como invocar un servicio o un observable. Importante: activities se va a deprecar en la próxima versión de XState, pero conviene reconocerlo si trabajas con código existente.

¿Cómo saber qué eventos puedo lanzar desde un estado?

La propiedad nextEvents retorna un array con los eventos válidos desde el estado actual. Si estás en búsqueda y desde ahí puedes ejecutar continuar o cancelar, ese array contendrá esos dos nombres. Es la forma más directa de saber qué transiciones tienes disponibles sin revisar la definición completa de la máquina.

¿Qué métodos te ayudan a consultar el estado actual?

XState expone métodos sobre el objeto state que simplifican validaciones comunes en tu código de aplicación.

¿Cómo funciona el método matches?

El método matches recibe el nombre de un estado y retorna true o false según coincida con el estado actual. Su valor real aparece cuando trabajas con máquinas anidadas o paralelas, donde value deja de ser un string y se vuelve un objeto. En esos casos, comparar manualmente se complica y matches resuelve la verificación tanto en máquinas padre como hijo.

javascript state.matches('initial'); // true si estás en initial state.matches('tickets'); // false si no estás ahí

¿Cómo verificar si un evento es válido con can?

El método can recibe el nombre de un evento y te dice si puede ejecutarse desde el estado actual. Las máquinas de estado bloquean por naturaleza las transiciones inválidas: si estás en initial y disparas finish, la máquina simplemente no hace nada. Con can puedes validar antes de llamar a send y evitar lógica muerta.

¿Qué hace el método can en XState? Recibe un evento como parámetro y retorna true si la transición es válida desde el estado actual, false si no lo es.

¿Cómo se ven estas propiedades en código real?

Al imprimir el objeto state con console.log, observas todas las propiedades juntas: el array de actions, activities, el objeto context, la bandera done que indica si es estado final, el event anterior, history en undefined cuando estás en el primer estado, la función matches, el objeto meta, el value ("initial" en este caso) y el array nextEvents.

En el ejemplo práctico, nextEvents muestra solo start como evento disponible. Al ejecutar:

• state.matches('initial') retorna true.
• state.matches('tickets') retorna false.
• state.can('finish') retorna false, coherente con que finish no aparece en nextEvents.

Con estas herramientas ya puedes leer de dónde vienes, dónde estás, qué eventos lanzaste antes y qué transiciones tienes disponibles. ¿Has usado matches o can en algún proyecto con máquinas anidadas? Cuéntame en los comentarios cómo resolviste tus validaciones.