Make sure useSelector.ts doesn’t create stale values

[enyo]

The function provided to svelte's readable is only invoked when the first subscriber subscribes to this store.

But because stately’s actor.subscribe does not fire immediately after subscribing (it only fires when something changes in the state) the svelte store could have a stale value (with the initial prevSelected) until the state in the machine changes and triggers the update.

This PR fixes that, by making sure that the value is not stale when the first subscription happens.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 904e6c4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a 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 904e6c4:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[ghost]

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

Legend

[Andarist]

Could you add a test case that would cover this case?

[enyo]

@Andarist done!

I think the comments in the code should be self descriptive, but here is a short summary since it’s pretty obscure Svelte behavior:

Using $count anywhere in the Svelte template, immediately creates a subscription of the store under the hood. That’s why it’s not possible to test this behavior with:

{#if $state.context.count >= 2}
  <div data-testid="selectorOutput”>{$count}</div>
{/if}

Instead I created another variable (readCount) that uses the get Svelte store function to read the value only when it’s supposed to be displayed (which means that the store is only subscribed to and read at a later time, and not from the start).

Without the fix in this PR, the value would still read 0 at the end, because the count store would still provide the initial value it received when it was created.

[enyo]

You might be wondering why this fix is needed in the first place, since you nearly always use a Svelte store in the template with the $count shorthand.

The bug appeared in our case, because we created the store and put it in a svelte context:

const count = useSelector(/* etc... */);
setContext(‘count’, count);

And then in some child component, at a later time, we used that store:

const count = getContext(‘count’);

And this is where the value was wrong.

[Andarist]

I wonder, are you using @xstate/svelte@beta by copy-pasting it into your project? That's fine - I was just double-checking things and this package isn't yet released, hence the question.

[enyo]

I wonder, are you using @xstate/svelte@beta by copy-pasting it into your project? That's fine - I was just double-checking things and this package isn't yet released, hence the question.

Yes that’s exactly what I’m doing.

[enyo]

The same bug exists in v4, but since I’m using v5 and this is going to be the next version anyway, I thought I might just fix it in v5 (especially since that is an edge case that probably not many people encounter).