Svelte integration

[jamesopstad]

Hi. I'm making a Svelte version of useMachine for @xstate/fsm based on the Vue and React implementations and have a couple of questions.

1. In the other implementations the options argument replaces any options already defined on the machine if it is provided. For my use, it makes more sense to merge so that actions can be provided in either locations (depending on whether they need access to the component instance). It would be nice to be consistent though so I was wondering if there's a reason not to do this.

2. Is it necessary to stop the service? If it needs to be stopped then I will wrap it in a Svelte readable store. Otherwise I can expose the service directly as it already implements the Svelte store contract.

Thanks!

[davidkpiano]

Awesome, looking forward to it!

Options are merged in, but it's done within machine.withConfig(...):

  public withConfig(
    options: Partial<MachineOptions<TContext, TEvent>>,
    context: TContext | undefined = this.context
  ): StateNode<TContext, TStateSchema, TEvent, TTypestate> {
    const { actions, activities, guards, services, delays } = this.options;

    return new StateNode(
      this.config,
      {
        actions: { ...actions, ...options.actions },
        activities: { ...activities, ...options.activities },
        guards: { ...guards, ...options.guards },
        services: { ...services, ...options.services },
        delays: { ...delays, ...options.delays }
      },
      context
    );
  }

Is it necessary to stop the service? If it needs to be stopped then I will wrap it in a Svelte readable store. Otherwise I can expose the service directly as it already implements the Svelte store contract.

Good question. If it's a "component-level" service (only active for the lifetime of the component), yes, it needs to be stopped if the component is no longer using it. Otherwise, it doesn't need to be stopped, as it's assumed something else manages the lifecycle of the service.

[Andarist]

Slight consideration for the merging behavior of options. I have always wanted to refactor the XState internals to avoid config changes so this:
https://github.com/davidkpiano/xstate/blob/597cfdc659b03f2095e73faf3f82702ae68a3911/packages/xstate-react/src/useMachine.ts#L230-L239
could be replaced with a simple assignment that would improve both implementation (right now we only update some of the options, but we probably should update most of them) and perf of React's useMachine.

[jamesopstad]

Great. I'll work on a version for xstate too when I have some time. Are you happy for me to make a new xstate-svelte package in the PR with a view to it eventually being distributed as @xstate/svelte?

[davidkpiano]

@jamesopstad That would be great!

[davidkpiano]

Slight consideration for the merging behavior of options. I have always wanted to refactor the XState internals to avoid config changes so this:
https://github.com/davidkpiano/xstate/blob/597cfdc659b03f2095e73faf3f82702ae68a3911/packages/xstate-react/src/useMachine.ts#L230-L239

could be replaced with a simple assignment that would improve both implementation (right now we only update some of the options, but we probably should update most of them) and perf of React's useMachine.

@Andarist We can consider this. My biggest fear is that this might be abused (well, sort of already currently is) by allowing the consumer to freely mutate .actions at any time.

[Andarist]

@Andarist We can consider this. My biggest fear is that this might be abused (well, sort of already currently is) by allowing the consumer to freely mutate .actions at any time.

Right - it's JavaScript though, hard to make this impossible without hiding everything in the closure which wouldn't be worth it. I feel that just hiding "private" stuff in the _-prefixed property should be enough for people to stay away from using/mutating it on their own.

[timdeschryver]

FWIW, I saw David's tweet about this discussion and wanted to mention that I also have a version of xstate-svelte (inspired by the react hooks). Feel free to take a look and take what you need if there's something useful there. Here's the link to the repo
I would love to see an official xstate-svelte package!

[jamesopstad]

Thanks! Hoping to start work on this soon.