Bug: State entry action's actor value mismatch about xstate HOT 9 OPEN

@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?

from xstate.

@crls-dray Would you want something like this?

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

  return {};
})

from xstate.

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

from xstate.

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.

from xstate.

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.

from xstate.

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.

from xstate.

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

from xstate.

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

from xstate.

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

from xstate.