v3.3.2

• More tests were added around the orthogonal (parallel) state value resolution logic, which was a regression from 3.2 but is now fixed.
  • Related issues: #117, #129
  • Related PRs: #119, #125 (thanks @AnimaLupi!)

v3.3.1

• History states are only kept on the most recent state. This does not affect existing behavior, and prevents memory leaks. 23c84e2
• Relative transitions are now all properly formatted, through all possible configurations. #117
• Substates with the same key as the parent state will no longer create an incorrect transition. #118

v3.3.0

There's so many exciting improvements and features in this release. In general, the internal algorithms for determining next state, as well as actions, activities, events, and more were heavily refactored to adhere closer to the SCXML spec, as well as be easier to understand and maintain in the codebase. There's always room for improvement though, and we're always open to PRs!

Features and Improvements

• Actions (onEntry, onExit, actions) can now be named functions, which should make authoring statecharts easier. #47 (📖 Docs)
  • They take in two arguments: extState (the external state passed into the transition(...) method) and event (the event object that caused the transition)
• Guards (cond on transition configs) can now be strings, and referenced by the guards object in the machine config. #57 (docs coming soon!)

const enoughTimeElapsed = (extState, event) => {
  return event.emergency || extState.elapsed > 300;
};

const lightMachine = Machine({
  initial: 'green',
  states: {
	green: {
	  on: {
		TIMER: {
		  // string conditional
		  yellow: { cond: 'enoughTimeElapsed' }
		},
	  }
	},
	yellow: { /* ... */ }
  }
}, {
  // guard config
  guards: { enoughTimeElapsed }
});

• Explicit history states - no more $history magic (this will still work and will be deprecated in 4.0). #86 (📖 Docs)

const historyMachine = Machine({
  initial: 'off',
  states: {
    fanOff: {
      on: {
        // transitions to history state
        POWER: 'fanOn.hist',
        HIGH_POWER: 'fanOn.highPowerHist'
      }
    },
    fanOn: {
      initial: 'first',
      states: {
        first: {
          on: { SWITCH: 'second' }
        },
        second: {
          on: { SWITCH: 'third' }
        },
        third: {},

        // shallow history state
        hist: {
          history: true
        },

        // shallow history state with default
        highPowerHist: {
          history: true,
          target: 'third'
        }
      },
      on: {
        POWER: 'fanOff'
      }
    }
  }
});

• The getShortestPaths graph function now works with conditional guards when passed an external state. #100
• Guard functions (cond) can now access the current state value, meaning you can use matchesState to determine if a transition should occur. #110
• Lots of tests have been added (over 300 now!) and xstate is now even closer to full SCXML compatibility (for most use cases, it's already compatible).

Special thanks to @mogsie for his contributions!

v3.2.0

Plenty of new improvements and features in this release! 🎉

• Support for metadata in state nodes, which are returned in the resulting State object. #45

{
  green: {
	on: { /* ... */ },
	data: {
	  name: 'Green Light'
	}
  }
}

• Transient states (with eventless transitions) and conditional transition arrays supported. #43

  const myMachine = Machine({
    initial: 'G',
    parallel: false,
    states: {
      G: {
        on: { UPDATE_BUTTON_CLICKED: 'E' }
      },
      E: {
        on: {
          // eventless transition
          '': [
            { target: 'D', cond: ({ data }) => !data }, // no data returned
            { target: 'B', cond: ({ status }) => status === 'Y' },
            { target: 'C', cond: ({ status }) => status === 'X' },
            { target: 'F' } // default, or just the string 'F'
          ]
        }
      },
      D: {},
      B: {},
      C: {},
      F: {}
    }
  });

• Partial support for SCXML conversion - full support coming 🔜
• State nodes can now be targeted directly via ID.
  • A state node can have the id: 'foobar' prop, for example
  • A transition can target that ID via { target: '#foobar' } (or just '#foobar').
• IDs can also be passed directly to machine.transition('#some-id', 'EVENT').
• Partial support for internal (local) transitions, using .childState syntax. See #71
• Multiple targets supported with array syntax, e.g., { target: ['foo.bar.one', 'foo.baz.quo'] }. #80
• Just like conditions, now you can used named functions as actions instead of just strings!
• matchesState will now return false if the parent state is more specific than the child state. #69

v3.1.1

Fixes

• Updated "main" field in package.json to point to the correct distributed file (dist/xstate.js).

v3.0.1

This is the officially published v3 of xstate! 🎉

Some changes from V1 and V2:

• machine.transition will always return a State object.
• 🆕 onEntry, onExit actions for states, and actions for transition actions
• 🆕 cond for conditional (guarded) transitions
• 🆕 strict: true for strict mode (helpful in development)
• Many more awesome things. For more information, read the docs.

If you're wondering why V3 and not V2:

1. Versions are cheap.
2. V2 was more of a sandbox version to test and dogfood new APIs. Those APIs have been solidified (thanks to help from the community) and have been released as V3, in case anyone (like myself) was using the undocumented V2 APIs.

v1.0.3

Fixes and enhancements

• The main script location in package.json was fixed, now it correctly points to dist/xstate.js.