v8.0.0

Major Changes

• #230 fdba194 Thanks @tivac! - Matching state and invoke names would cause xstate-component-tree to fail to return child components in some cases because internally it named them the same thing and stomped all over itself.

  states : {
      foo : {
          invoke : {
              id : "foo",
              // ...
          },
      },
  },
  

  This should work now.

  BREAKING CHANGE: All machine values in the output that previously looked like root.foo will now look like root.#foo, in order to help differentiate the child machine id from the parent state path.

v7.1.0

Minor Changes

• ca3d879 Thanks @tivac! - Fixed issue where newly-created actors were immediately receiving the event that had been .broadcast(...).

  This was happening because the actors were being iterated in such a way that new actors added because of the event were also being iterated. This led to weird behaviors where events would seem to be duplicated.

v7.0.1

Patch Changes

• a37d587 Thanks @tivac! - Fixed up type generation and some internal naming to match xstate v5 conventions

v6.1.1

Patch Changes

• #119 743433d Thanks @tivac! - Support multiple invoked items per state

  Previously it would only use the last invocation at each state.

v6.1.0

Minor Changes

• #117 0cec0db Thanks @tivac! - Add machine info to each result

  Otherwise root components of parallel sibling child machines can end up not being actually comparable.

  [
      [Object: null prototype] {
  +       machine: "(machine).child-one",
          path: false,
          component: [Function: child],
          props: false,
          children: []
      },
      [Object: null prototype] {
  +       machine: "(machine).child-two",
          path: false,
          component: [Function: child],
          props: false,
          children: []
      }
  ]

v6.0.2

Patch Changes

• #115 51cfe5e Thanks @tivac! - Fix an issue where in specific situations child trees would not be built.

  If a child machine has an invoke that immediately triggers a no-op event, the ComponentTree instance wouldn't actually walk that child machine for components to render. This was due to an interesting interaction between the xstate .changed property and when invokes within the statechart are run.

  Now whenever the ComponentTree sees a new machine it hasn't walked is running, it will walk it.

v6.0.1

Patch Changes

• 048060a Thanks @tivac! - Fix exports config

v6.0.0

Major Changes

• #111 a0ec633 Thanks @tivac! - Add .d.ts files to releases and restructure exports.

  Previously

  import ComponentTree from "xstate-component-tree";
  import componentHelper from "xstate-component-tree/component";
  

  Now

  import { ComponentTree, componentHelper } from "xstate-component-tree";
  

Minor Changes

• #113 88d1dba Thanks @tivac! - Component helper preserves .meta fields

  Previous using the helper like this:

  helper(Component, {
    meta: {
      fooga: "wooga",
    },
  });

  would return an object with no meta.fooga property. Now those keys are properly preserved if they exist.

  meta.load will still be overwritten if it exists, because it is required for the helper to function. A warning if it exists may be introduced in a future release.

v5.2.0

Minor Changes

• #98 e7cd20d Thanks @tivac! - Support for components at the root of machines

  createMachine({
    initial: "foo",
  
    meta: {
      component: RootComponent,
    },
  
    states: {
      foo: {
        meta: {
          component: FooComponent,
        },
      },
    },
  });

  Previously RootComponent would be ignored, now it will be the first component in the tree and FooComponent will be placed as a child of it.

v5.1.0

Minor Changes

• #74 951cea7 Thanks @tivac! - Adding .can() API from XState

  The .can() API is a simple passthrough to the interpreter for the root statechart being managed by xstate-component-tree, and is intended as a convenience function to make it easier to interact with a ComponentTree instance instead of a direct XState Interpreter reference.

  From the XState docs on .can():

  Determines whether sending the event will cause a non-forbidden transition to be selected, even if the transitions have no actions nor change the state value.