Xstate: Transition handled by parallel states

Created on 27 Mar 2018  路  7Comments  路  Source: davidkpiano/xstate

Hello, let me first say I'm not sure this is a bug, I'm having doubts about my understanding of state charts and consequently of my expectations about their behaviour.

Anyway, I'm using this config:

const wakMachineConfig = {
  id: 'wakMachine',
  parallel: true,
  strict: true,
  states: {
    wak1: {
      initial: 'wak1sonA',
      states: {
        wak1sonA: {
          onEntry: 'wak1sonAenter',
          onExit: 'wak1sonAexit'
        },
        wak1sonB: {
          onEntry: 'wak1sonBenter',
          onExit: 'wak1sonBexit'
        }
      },
      on: {
        WAK1: '.wak1sonB'
      },
      onEntry: 'wak1enter',
      onExit: 'wak1exit'
    },
    wak2: {
      initial: 'wak2sonA',
      states: {
        wak2sonA: {
          onEntry: 'wak2sonAenter',
          onExit: 'wak2sonAexit'
        },
        wak2sonB: {
          onEntry: 'wak2sonBenter',
          onExit: 'wak2sonBexit'
        }
      },
      on: {
        WAK2: '.wak2sonB'
      },
      onEntry: 'wak2enter',
      onExit: 'wak2exit'
    }
  }
};

let stateMachine = xstate.Machine(wakMachineConfig);

let currentState = stateMachine.initialState;

If I check currentState at this point is:

{ wak1: 'wak1sonA', wak2: 'wak2sonA'}

I then issue a very simple transition like:

currentState = stateMachine.transition(currentState, 'WAK1');

My expectations would be like this:

currentState.value : {wak1: "wak1sonB", wak2: "wak2sonA"}

but I'm getting :

currentState.value: {wak1: wak1sonB}

Why is that happening? By looking at the examples I had the impression that the transition would return the whole machine state, not just the affected sub state. Is this a wrong assumption?
Can you point me to my mistake? Because right now I can't chain another transition with the event "WAK2", for example.

Or did I stumble upon a bug instead?

I'll try to link to codepen for the whole example: link

Thank you,

Andrea

bug

Most helpful comment

@AnimaLupi FYI tests are passing in the SCXML branch, as expected 馃檶

All 7 comments

Thanks for the details and codepen example! It might be a bug, but it's probably one that's already fixed in a separate branch. I'm planning on releasing 3.2 馃敎 but I'll add this as a test case, because you're right; this should be the expected value: {wak1: "wak1sonB", wak2: "wak2sonA"}.

I'll make sure this is fixed before 3.2 is released!

Ah, cool! Thank you very much then!

@AnimaLupi FYI tests are passing in the SCXML branch, as expected 馃檶

Haha, I thought I fetched before I started this. Doh!

Fixed in 5278351be8b9d98cfb169997597eccdf1b15c2da

Hello,
I'm still having issue regarding this topic.
I tried 3.2 in my current project and strangely I still saw same wrong behaviour.
I then tried to run your test suit and I saw the test passed.

I made a change to the test though (I'm pasting here changes as a diff, not sure if there's a better way):

165c165
<     const nextState = wakMachine.transition(wakMachine.initialState, 'WAK1');
---
>     const nextState = wakMachine.transition(wakMachine.initialState, 'WAK2');
167c167
<     assert.deepEqual(nextState.value, { wak1: 'wak1sonB', wak2: 'wak2sonA' });
---
>     assert.deepEqual(nextState.value, { wak1: 'wak1sonA', wak2: 'wak2sonB' });

Which basically sends event WAK2 which should transition to { wak1: 'wak1sonA', wak2: 'wak2sonB' } but this doesn't happen and the test fails.

Am I missing something stupid or is there some kind of bug regarding order of declarations or something similar?

Thank you very much,

Andrea

Hey @AnimaLupi thanks for the investigation, I'll look into it. Your thinking is correct.

Was this page helpful?
0 / 5 - 0 ratings