Bug: State entry action's actor value mismatch

[carlos-sonatafy]

XState version

XState version 5

Description

While trying to read the actor's current value/active state using self.getSnapshot().value, the actual value is that of the actor before entering the new state.

As an example, consider the following statechart:

https://stately.ai/registry/editor/embed/0e3cf46a-a74e-4fc2-8161-dcbcec137965?machineId=522c8104-73e6-40d6-922c-30917b52733f

const myAction = assign(({ self }) => {
  console.log(self.getSnapshot().value);

  return {};
})

The action prints First State instead of Second State.

Expected result

Because the action is an entry action for a specific state - not a transition - I'd expect the actual value to be Second State

Actual result

The value is First State

Reproduction

https://stately.ai/registry/editor/0e3cf46a-a74e-4fc2-8161-dcbcec137965?machineId=522c8104-73e6-40d6-922c-30917b52733f

Additional context

No response

[davidkpiano]

This is working as expected. The snapshot isn't committed until all of the actions have been executed.

[carlos-sonatafy]

@davidkpiano I mean, I understand that portion - and I know my knowledge about statecharts is lesser than yours - but it kind of doesn't make sense.

If we're talking about an action that executes while entering a state, shouldn't said action be able to consult the statechart's active state?

And if that holds true, shouldn't the active state (value) be the same state it was entered and not the one before transitioning?

[davidkpiano]

@crls-dray Would you want something like this?

// PSEUDOCODE
const myAction = assign(({ stateNode }) => {
  console.log(stateNode.id); // e.g. "someMachine.loading"

  return {};
})

[carlos-sonatafy]

Yes, that might work - not sure how'd that translate for parallel states, that's why I thought the actual value would be the same as the snapshot.value. I'm not using parallel states, just mentioning it.

---

My use-case is that I have an action which is loading some data into the context, and such data is active-state specific.

The statechart is being defined in Stately Studio, the main purpose is to allow non-dev coworkers of mine to model the statechart with minimal overhead due to implementation specifics - thus why I can take away the implementation specifics if I'm able to load the info based on the current/active state.

[carlosbensant]

I have the same use case as @cris-dray. I have a state property in my context loadingStatus.text that I want to be updated every time a state transition occurs.

[carlosbensant]

Based on vck3000's response, I can see this has been the current implementation for a long while, I would like to understand but it doesn't make sense as for me, anytime you add an entry action property to a state, we expect it to match the current state value where the action is placed.

[carlosbensant]

My current implementation looks like this but I have plenty of actions and state transitions (to notify the user, to update timestamp, etc):

import { setup, assign } from 'xstate';

const createDogMachine = (contextFromDB) => {
  return setup({
    actions: {
      updateContext: assign({
        state: (_, params) => params.state,
      }),
    }
  }).createMachine({
    id: 'dog',
    initial: contextFromDB.state || 'asleep',
    context: contextFromDB,
    states: {
      asleep: {
        entry: [
          {
            type: 'updateContext',
            params: {
              state: 'asleep', // current state
            }
          }
        ],
        on: {
          'wakes up': 'awake',
        }
      },
      awake: {
        entry: [
          {
            type: 'updateContext',
            params: {
              state: 'awake', // current state
            }
          }
        ],
        on: {
          'falls asleep': 'asleep',
        }
      },
      //...
    }
  });
}

gist: https://gist.github.com/carlosbensant/21adcd22373d16f1388f283a9b53a17f

[davidkpiano]

cc. @Andarist - I know that you had opinions/thoughts on this

[Andarist]

I think giving the user access to the state node that triggers the action would be nice, something like in #4217