Skip to content

Latest commit

 

History

History
381 lines (262 loc) · 23.3 KB

CHANGELOG.md

File metadata and controls

381 lines (262 loc) · 23.3 KB
Raw

xstate

4.15.1

Patch Changes

  • 8a8cfa32 #1704 Thanks @blimmer! - The default clock methods (setTimeout and clearTimeout) are now invoked properly with the global context preserved for those invocations which matter for some JS environments. More details can be found in the corresponding issue: #1703.

4.15.0

Minor Changes

  • 6596d0ba #1622 Thanks @davidkpiano! - Spawned/invoked actors and interpreters are now typed as extending ActorRef (e.g., SpawnedActorRef) rather than Actor or Interpreter. This unification of types should make it more straightforward to provide actor types:

    import {
- Actor
+ ActorRef
} from 'xstate';

// ...

interface SomeContext {
- server?: Actor;
+ server?: ActorRef<ServerEvent>;
}

    It's also easier to specify the type of a spawned/invoked machine with ActorRefFrom:

    import {
  createMachine,
- Actor
+ ActorRefFrom
} from 'xstate';

const serverMachine = createMachine<ServerContext, ServerEvent>({
  // ...
});

interface SomeContext {
- server?: Actor; // difficult to type
+ server?: ActorRefFrom<typeof serverMachine>;
}

Patch Changes

  • 75a91b07 #1692 Thanks @Andarist! - Fixed an issue with history state entering a wrong state if the most recent visit in its parent has been caused by a transient transition.

4.14.1

Patch Changes

  • 02c76350 #1656 Thanks @Andarist! - Exit actions will now be properly called when a service gets canceled by calling its stop method.

4.14.0

Minor Changes

  • 119db8fb #1577 Thanks @davidkpiano! - Expressions can now be used in the stop() action creator:

    // ...
actions: stop(context => context.someActor);

Patch Changes

  • 8c78e120 #1570 Thanks @davidkpiano! - The return type of spawn(machine) will now be Actor<State<TContext, TEvent>, TEvent>, which is a supertype of Interpreter<...>.
  • 602687c2 #1566 Thanks @davidkpiano! - Exit actions will now be properly called when an invoked machine reaches its final state. See #1109 for more details.
  • 6e44d02a #1553 Thanks @davidkpiano! - The state.children property now properly shows all spawned and invoked actors. See #795 for more details.
  • 72b0880e #1504 Thanks @Andarist! - Added status property on the Interpreter - this can be used to differentiate not started, running and stopped interpreters. This property is best compared to values on the new InterpreterStatus export.

4.13.0

Minor Changes

  • f51614df #1409 Thanks @jirutka! - Fix type ExtractStateValue so that it generates a type actually describing a State.value

Patch Changes

  • b1684ead #1402 Thanks @Andarist! - Improved TypeScript type-checking performance a little bit by using distributive conditional type within TransitionsConfigArray declarations instead of a mapped type. Kudos to @amcasey, some discussion around this can be found here
  • ad3026d4 #1407 Thanks @tomenden! - Fixed an issue with not being able to run XState in Web Workers due to assuming that window or global object is available in the executing environment, but none of those are actually available in the Web Workers context.

  • 4e949ec8 #1401 Thanks @Andarist! - Fixed an issue with spawned actors being spawned multiple times when they got spawned in an initial state of a child machine that is invoked in the initial state of a parent machine.

    Illustrating example for curious readers. 
    const child = createMachine({
  initial: 'bar',
  context: {},
  states: {
    bar: {
      entry: assign({
        promise: () => {
          return spawn(() => Promise.resolve('answer'));
        }
      })
    }
  }
});

const parent = createMachine({
  initial: 'foo',
  states: {
    foo: {
      invoke: {
        src: child,
        onDone: 'end'
      }
    },
    end: { type: 'final' }
  }
});

interpret(parent).start();

4.12.0

Minor Changes

  • b72e29dd #1354 Thanks @davidkpiano! - The Action type was simplified, and as a result, you should see better TypeScript performance.

  • 4dbabfe7 #1320 Thanks @davidkpiano! - The invoke.src property now accepts an object that describes the invoke source with its type and other related metadata. This can be read from the services option in the meta.src argument:

    const machine = createMachine(
  {
    initial: 'searching',
    states: {
      searching: {
        invoke: {
          src: {
            type: 'search',
            endpoint: 'example.com'
          }
          // ...
        }
        // ...
      }
    }
  },
  {
    services: {
      search: (context, event, { src }) => {
        console.log(src);
        // => { endpoint: 'example.com' }
      }
    }
  }
);

    Specifying a string for invoke.src will continue to work the same; e.g., if src: 'search' was specified, this would be the same as src: { type: 'search' }.

  • 8662e543 #1317 Thanks @Andarist! - All TTypestate type parameters default to { value: any; context: TContext } now and the parametrized type is passed correctly between various types which results in more accurate types involving typestates.

Patch Changes

  • 3ab3f25e #1285 Thanks @Andarist! - Fixed an issue with initial state of invoked machines being read without custom data passed to them which could lead to a crash when evaluating transient transitions for the initial state.

  • a7da1451 #1290 Thanks @davidkpiano! - The "Attempted to spawn an Actor [...] outside of a service. This will have no effect." warnings are now silenced for "lazily spawned" actors, which are actors that aren't immediately active until the function that creates them are called:

    // ⚠️ "active" actor - will warn
spawn(somePromise);

// 🕐 "lazy" actor - won't warn
spawn(() => somePromise);

// 🕐 machines are also "lazy" - won't warn
spawn(someMachine);

    It is recommended that all spawn(...)-ed actors are lazy, to avoid accidentally initializing them e.g., when reading machine.initialState or calculating otherwise pure transitions. In V5, this will be enforced.

  • c1f3d260 #1317 Thanks @Andarist! - Fixed a type returned by a raise action - it's now RaiseAction<TEvent> | SendAction<TContext, AnyEventObject, TEvent> instead of RaiseAction<TEvent> | SendAction<TContext, TEvent, TEvent>. This makes it comaptible in a broader range of scenarios.
  • 8270d5a7 #1372 Thanks @christianchown! - Narrowed the ServiceConfig type definition to use a specific event type to prevent compilation errors on strictly-typed MachineOptions.
  • 01e3e2dc #1320 Thanks @davidkpiano! - The JSON definition for stateNode.invoke objects will no longer include the onDone and onError transitions, since those transitions are already merged into the transitions array. This solves the issue of reviving a serialized machine from JSON, where before, the onDone and onError transitions for invocations were wrongly duplicated.

4.11.0

Minor Changes

  • 36ed8d0a #1262 Thanks @Andarist! - Improved type inference for InvokeConfig['data']. This has required renaming data property on StateNode instances to doneData. This property was never meant to be a part of the public API, so we don't consider this to be a breaking change.

  • 2c75ab82 #1219 Thanks @davidkpiano! - The resolved value of the invoke.data property is now available in the "invoke meta" object, which is passed as the 3rd argument to the service creator in options.services. This will work for all types of invoked services now, including promises, observables, and callbacks.

    const machine = createMachine({
  initial: 'pending',
  context: {
    id: 42
  },
  states: {
    pending: {
      invoke: {
        src: 'fetchUser',
        data: {
          userId: (context) => context.id
        },
        onDone: 'success'
      }
    },
    success: {
      type: 'final'
    }
  }
},
{
  services: {
    fetchUser: (ctx, _, { data }) => {
      return fetch(`some/api/user/${data.userId}`)
        .then(response => response.json());
    }
  }
}

  • a6c78ae9 #1249 Thanks @davidkpiano! - New property introduced for eventless (transient) transitions: always, which indicates a transition that is always taken when in that state. Empty string transition configs for transient transitions are deprecated in favor of always:

    // ...
states: {
  playing: {
+   always: [
+     { target: 'win', cond: 'didPlayerWin' },
+     { target: 'lose', cond: 'didPlayerLose' },
+   ],
    on: {
      // ⚠️ Deprecation warning
-     '': [
-       { target: 'win', cond: 'didPlayerWin' },
-       { target: 'lose', cond: 'didPlayerLose' },
-     ]
    }
  }
}
// ...

    The old empty string syntax ('': ...) will continue to work until V5.

Patch Changes

  • 36ed8d0a #1262 Thanks @Andarist! - StateMachine<any, any, any> is no longer a part of the InvokeConfig type, but rather it creates a union with InvokeConfig in places where it is needed. This change shouldn't affect consumers' code.

4.10.0

Minor Changes

  • 0133954 #1178 Thanks @davidkpiano! - The types for the send() and sendParent() action creators have been changed to fix the issue of only being able to send events that the machine can receive. In reality, a machine can and should send events to other actors that it might not be able to receive itself. See #711 for more information.
  • a1f1239 #1189 Thanks @davidkpiano! - Previously, state.matches(...) was problematic because it was casting state to never if it didn't match the state value. This is now fixed by making the Typestate resolution more granular.
  • dbc6a16 #1183 Thanks @davidkpiano! - Actions from a restored state provided as a custom initial state to interpret(machine).start(initialState) are now executed properly. See #1174 for more information.

Patch Changes

  • 326db72 #1185 Thanks @Andarist! - Fixed an issue with invoked service not being correctly started if other service got stopped in a subsequent microstep (in response to raised or null event).
  • c3a496e #1160 Thanks @davidkpiano! - Delayed transitions defined using after were previously causing a circular dependency when the machine was converted using .toJSON(). This has now been fixed.
  • e16e48e #1153 Thanks @Andarist! - Fixed an issue with choose and pure not being able to use actions defined in options.
  • d496ecb #1165 Thanks @davidkpiano! - XState will now warn if you define an .onDone transition on the root node. Root nodes which are "done" represent the machine being in its final state, and can no longer accept any events. This has been reported as confusing in #1111.

4.9.1

Patch Changes

  • 8a97785 #1137 Thanks @davidkpiano! - Added docs for the choose() and pure() action creators, as well as exporting the pure() action creator in the actions object.
  • e65dee9 #1131 Thanks @wKovacs64! - Include the new choose action in the actions export from the xstate core package. This was missed in v4.9.0.

4.9.0

Minor Changes

  • f3ff150 #1103 Thanks @davidkpiano! - Simplify the TransitionConfigArray and TransitionConfigMap types in order to fix excessively deep type instantiation TypeScript reports. This addresses #1015.

  • 6c47b66 #1076 Thanks @Andarist! - Added support for conditional actions. It's possible now to have actions executed based on conditions using following:

    entry: [
  choose([
    { cond: ctx => ctx > 100, actions: raise('TOGGLE') },
    {
      cond: 'hasMagicBottle',
      actions: [assign(ctx => ({ counter: ctx.counter + 1 }))]
    },
    { actions: ['fallbackAction'] }
  ])
];

    It works very similar to the if-else syntax where only the first matched condition is causing associated actions to be executed and the last ones can be unconditional (serving as a general fallback, just like else branch).

Patch Changes

  • 1a129f0 #1073 Thanks @Andarist! - Cleanup internal structures upon receiving termination events from spawned actors.
  • e88aa18 #1085 Thanks @Andarist! - Fixed an issue with data expressions of root's final nodes being called twice.

  • 88b17b2 #1090 Thanks @rjdestigter! - This change carries forward the typestate type information encoded in the arguments of the following functions and assures that the return type also has the same typestate type information:

    • Cloned state machine returned by .withConfig.
    • .state getter defined for services.
    • start method of services.

4.8.0

Minor Changes

  • 55aa589 #960 Thanks @davidkpiano! - The machine can now be safely JSON-serialized, using JSON.stringify(machine). The shape of this serialization is defined in machine.schema.json and reflected in machine.definition.

    Note that onEntry and onExit have been deprecated in the definition in favor of entry and exit.

Patch Changes

4.7.8

Patch Changes

4.7.7

Patch Changes

  • c8db035 #936 Thanks @davidkpiano! - The escalate() action can now take in an expression, which will be evaluated against the context, event, and meta to return the error data.
  • 2a3fea1 #952 Thanks @davidkpiano! - The typings for the raise() action have been fixed to allow any event to be raised. This typed behavior will be refined in version 5, to limit raised events to those that the machine accepts.
  • f86d419 #957 Thanks @Andarist! - Fixed memory leak - each created service has been registered in internal map but it was never removed from it. Registration has been moved to a point where Interpreter is being started and it's deregistered when it is being stopped.

4.7.6

Patch Changes

  • dae8818: Typestates are now propagated to interpreted services.

4.7.5

Patch Changes

  • 6b3d767: Fixed issue with delayed transitions scheduling a delayed event for each transition defined for a single delay.

4.7.4

Patch Changes

  • 9b043cd: The initial state is now cached inside of the service instance instead of the machine, which was the previous (faulty) strategy. This will prevent entry actions on initial states from being called more than once, which is important for ensuring that actors are not spawned more than once.

4.7.3

Patch Changes

  • 2b134eee: Fixed issue with events being forwarded to children after being processed by the current machine. Events are now always forwarded first.
  • 2b134eee: Fixed issue with not being able to spawn an actor when processing an event batch.