Get reference to current state in guard function

[alex-dixon]

Hello! Would it be possible to pass a reference to guard functions that allow accessing self or similar to allow accessing the current state? Thanks!

[davidkpiano]

What is your use-case?

cc. @Andarist

[davidkpiano]

So you want to use it for inspection, basically?

We will be improving the XState v5 inspection API, which currently allows you to listen for snapshots, events, and actor registration inspection events. Listening for more granular events (actions and transitions) is something we can add.

This can look something like this:

// pseudocode
const actor = createActor(machine, {
  inspect: (ev) => {
    if (ev.type === '@xstate.transition') {
      console.log(ev.guard); // which guard passed?
    }
  }
});

[alex-dixon]

Having a global listener for all state machine activations would be really great also. I could see it supporting more advanced use cases and tooling. I used to have something very similar and it was a lot of fun :)

At the moment, we want state paths/values as contextual information in logs for all functions (guards, actions, actors, delays) (and the functions they call...etc).

Our logger manages named spans, context, timings, etc. Being able to put the state path/value on all our logs would be valuable. It'd be straightforward to implement on our end,. basically just:

const guards = {
  'my-guard': ({ context, self, event }) => {
  let guardId = `${self.getSnapshot().value}/my-guard`
  let log = logger.withSpan(guardId)
  try {
    log.debug("evaluating something...")
   return event.foo ? true 
  } catch (e) {
    log.error("Unhandled exception", e)
   return false
  }
}

Logs would be something like

[debug][my-machine.my-state.my-guard] evaluating something... (1ms)
[error][my-machine.my-state.my-guard] Unhandled exception <error> (3ms)

[ShravanSunder]

@davidkpiano I was planning on using the current state tag in my guard logic.

[Andarist]

U have a hasTag guard (in v5) that u can use for this purpose

[alex-dixon]

@Andarist I don’t see a hasTag guard.

I’d still be in support of this. It would let users implement things like hasTag, hasMeta, arbitrary predicates as a function of state, context and event, etc.

Looking at the source I think it could simplify the code too. Framework-provided guards and user-defined guards could use the same function signatures. The calling side could pass the same arguments for all guards.