[@xstate/store] Refactor store logic to improve context updates and snapshot handling

[davidkpiano]

• Removed unused setter function and associated recipe parameter.
• Updated transition logic to prevent unnecessary updates when the snapshot remains unchanged.
• Enhanced tests to verify behavior of effect-only and emit-only transitions, ensuring no updates trigger when the snapshot is the same.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5eda50b

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

This PR includes changesets to release 1 package

Name	Type
@xstate/store	Minor

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

[Andarist]

note this diverges from XState too:

import { createActor, createMachine } from "xstate";

const m = createMachine({
  on: {
    FOO: {
      actions: () => {},
    },
  },
});

const a = createActor(m).start();

let s = a.getSnapshot();

a.subscribe((_s) => {
  console.log("next", s === _s, _s);
  s = _s;
});

a.send({ type: "FOO" });
a.send({ type: "FOO" });
a.send({ type: "FOO" });

With the above we get:

[davidkpiano]

What do you think about this behavior? If only actions/effects occur (invisible to the state, at least right now), then the state is going to be exactly the same. But I guess that's the responsibility of the consumer to "filter"

[Andarist]

Similarly here, I think it would be totally OK to filter those out - but I think it would be great if this could be consistent between XState libraries.

[davidkpiano]

Yes, I think in XState v6, the purpose of the observer is to observe snapshot changes, so notifying on the same snapshot isn't useful.