Skip to content

Releases: statelyai/xstate

@xstate/[email protected]

14 Dec 14:33
428c3cd
Compare
Choose a tag to compare

Minor Changes

  • a473205d #1699 Thanks @davidkpiano! - The @xstate/inspect tool now uses fast-safe-stringify for internal JSON stringification of machines, states, and events when regular JSON.stringify() fails (e.g., due to circular structures).

[email protected]

07 Dec 21:51
b72c6c2
Compare
Choose a tag to compare

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.

[email protected]

06 Dec 15:07
cd711ba
Compare
Choose a tag to compare

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.

@xstate/[email protected]

06 Dec 15:07
cd711ba
Compare
Choose a tag to compare

Minor Changes

  • 89f9c27c #1622 Thanks @davidkpiano! - Spawned/invoked actors and interpreters are now typed as extending ActorRef rather than Actor or Interpreter. This unification of types should make it more straightforward to provide actor types in React:

    import { ActorRef } from 'xstate';
    import { useActor } from '@xstate/react';
    
    const Child: React.FC<{ actorRef: ActorRef<SomeEvent, SomeEmitted> }> = ({
      actorRef
    }) => {
      // `state` is typed as `SomeEmitted`
      // `send` can be called with `SomeEvent` values
      const [state, send] = useActor(actorRef);
    
      // . ..
    };

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

    import { createMachine, ActorRefFrom } from 'xstate';
    import { useActor } from '@xstate/react';
    
    const someMachine = createMachine<SomeContext, SomeEvent>({
      // ...
    });
    
    const Child: React.FC<{ someRef: ActorRefFrom<typeof someMachine> }> = ({
      someRef
    }) => {
      // `state` is typed as `State<SomeContext, SomeEvent>`
      // `send` can be called with `SomeEvent` values
      const [state, send] = useActor(someRef);
    
      // . ..
    };

@xstate/[email protected]

28 Nov 19:28
80ea4ba
Compare
Choose a tag to compare

Minor Changes

  • 111a7d13 #1663 Thanks @davidkpiano! - Options passed into graph functions (e.g., getShortestPaths(machine, options)) can now resolve .events based on the state:

    const countMachine = createMachine({
      initial: 'active',
      context: {
        count: 0
      },
      states: {
        active: {
          on: {
            ADD: {
              actions: assign({
                count: (context, event) => {
                  return context.count + event.value;
                }
              })
            }
          }
        }
      }
    });
    
    const shortestPaths = getShortestPaths(countMachine, {
      events: {
        ADD: state => {
          // contrived example: if `context.count` is >= 10, increment by 10
          return state.context.count >= 10
            ? [{ type: 'ADD', value: 10 }]
            : [{ type: 'ADD', value: 1 }];
        }
      }
    });
    
    // The keys to the shortest paths will look like:
    // "active" | { count: 0 }
    // "active" | { count: 1 }
    // "active" | { count: 2 }
    // ...
    // "active" | { count: 10 }
    // "active" | { count: 20 }
    // "active" | { count: 30 }

@xstate/[email protected]

26 Nov 16:57
d5d4d5c
Compare
Choose a tag to compare

Patch Changes

  • 8b670653 #1661 Thanks @Andarist! - Fixed an issue with initial assign actions not being resolved and thus context not being updated by them.

[email protected]

25 Nov 17:29
227d81b
Compare
Choose a tag to compare

Patch Changes

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

@xstate/[email protected]

15 Nov 13:15
6c1ffa1
Compare
Choose a tag to compare

Patch Changes

[email protected]

05 Nov 13:00
b228ade
Compare
Choose a tag to compare

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.

@xstate/[email protected]

05 Nov 13:00
b228ade
Compare
Choose a tag to compare

Patch Changes

  • c7927083 #1516 Thanks @davidkpiano! - The send function returned from the useService() now can take two arguments (an event type and payload), to match the behavior of @xstate/react version 0.x.

  • db77623a #1516 Thanks @davidkpiano! - The send value returned from the useService() hook will now accept a payload, which matches the signature of the send value returned from the useMachine() hook:

    const [state, send] = useService(someService);
    
    // ...
    
    // this is OK:
    send('ADD', { value: 3 });
    
    // which is equivalent to:
    send({ type: 'ADD', value: 3 });
  • 93f6db02 #1594 Thanks @Andarist! - Fixed an issue with internal setState in useService being called with 2 arguments instead of 1.

  • 72b0880e #1504 Thanks @Andarist! - Fixed issue with useService returning an initial state for services in their final states.