[v5] Remove observable replay

[davidkpiano]

This PR makes actor.subscribe(...) a hot observable; it will no longer emit the current snapshot, which can be retrieved synchronously via actor.getSnapshot().

[linear]

STA-498

[changeset-bot]

🦋 Changeset detected

Latest commit: ddf64b6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
xstate	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit ddf64b6:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[davidkpiano]

@GoldingAustin Do you know what can be done here to make @xstate/solid work with the actor (service) as a hot observable? We can still get the initial state from actor.getSnapshot().

[tivac]

I can't look at the Linear ticket but would love to understand the reasoning behind this change. I'm used to svelte store style observables so .subscribe() immediately sending the current value was exactly how I expected it to work.

[Andarist]

Often u might be interested to listen for a change. This might be different from UI-related needs where you might want to render a retrieved value immediately though. The point is that if you want to listen for a change then it's really quirky to ignore the first emitted value but when you want to combine change+current value... that is more straightforward to do.

[tivac]

Thanks for explaining the reasoning @Andarist, I really appreciate the insight. I'm firmly over here in UI-land so this isn't a change I'm excited about but at least I understand it now.

[davidkpiano]

Thanks for explaining the reasoning @Andarist, I really appreciate the insight. I'm firmly over here in UI-land so this isn't a change I'm excited about but at least I understand it now.

@tivac You're in luck; since @xstate/svelte implements stores like this:

  //  initial snapshot   vvvvvvvvvvvvvvvvvvvvv
  const state = readable(service.getSnapshot(), (set) => {
    return service.subscribe((state) => {
      if (state.changed) {
        set(state);
      }
    }).unsubscribe;
  });

I believe everything will still work the same, and you will have the initial snapshot available immediately regardless of these changes. It might even work better because you won't get a redundant update (two initial snapshots - one with .getSnapshot() and one upon subscribing).

[tivac]

I'm mostly subscribing to interpreters via xstate-component-tree these days, but that library will certainly be updated to work with v5 so it's not a huge deal.

[ghost]

👇 Click on the image for a new way to code review

Legend

[davidkpiano]

It seems like the only failing tests are for @xstate/solid - @GoldingAustin can you help with this?

The context is that .subscribe will no longer receive the current snapshot; that needs to be read from actor.getSnapshot().

[GoldingAustin]

I'll take a look at this today!

[GoldingAustin]

It seems like the only failing tests are for @xstate/solid - @GoldingAustin can you help with this?

The context is that .subscribe will no longer receive the current snapshot; that needs to be read from actor.getSnapshot().

This will be a quick fix; I'll remove the from test suite. I can update the current tests to not use from or create a new function export from xstate-solid that emulates the past from functionality. Do you have any preferences on the direction?

[davidkpiano]

It seems like the only failing tests are for @xstate/solid - @GoldingAustin can you help with this?
The context is that .subscribe will no longer receive the current snapshot; that needs to be read from actor.getSnapshot().

This will be a quick fix; I'll remove the from test suite. I can update the current tests to not use from or create a new function export from xstate-solid that emulates the past from functionality. Do you have any preferences on the direction?

I think the new function export would be the best direction (cc. @Andarist)

[Andarist]

Yeah, I think that a new export is the best solution here - unless from is already easily replaceable with something. Isn't this mostly the same thing?

-const state = from(actor)
+const [state] = useActor(actor)

A notable difference is that useActor used the whole createImmutable under the hood... but that feels like an improvement, right?

[Andarist]

note for me - this might require a small tweak in the wording if we decide to go with #3912