[@xstate/store] createStoreLogic and selectors

[davidkpiano]

Added createStoreLogic for reusable store definitions with input and selectors support for both createStore and createStoreLogic.

const counterLogic = createStoreLogic({
  context: (input: { initialCount: number }) => ({
    count: input.initialCount
  }),
  on: {
    inc: (ctx) => ({ count: ctx.count + 1 })
  },
  selectors: {
    doubled: (ctx) => ctx.count * 2
  }
});

const counter1 = counterLogic.createStore({ initialCount: 42 });
const counter2 = counterLogic.createStore({ initialCount: 0 });

counter1.selectors.doubled.get(); // 84

Selectors are reactive ReadonlyAtoms (powered by store.select()), composable with createAtom, and preserved through .with() extensions.

[changeset-bot]

🦋 Changeset detected

Latest commit: 81648e8

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

This PR includes changesets to release 7 packages

Name	Type
@xstate/store	Minor
@xstate/store-angular	Patch
@xstate/store-preact	Patch
@xstate/store-react	Patch
@xstate/store-solid	Patch
@xstate/store-svelte	Patch
@xstate/store-vue	Patch

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 that all of my comments are just questions, not suggestions

[Andarist]

q: will this work properly with multi-layer .with calls? like x.with().with().with(). It feels like it will lead to calling attachSelectors for each of those layers and I wonder if that's a) optimal b) correct

[Andarist]

on that point, why emits and selectors are threaded through things differently? emits go through createStoreCore and selectors go through attachSelectors

[davidkpiano]

q: will this work properly with multi-layer .with calls? like x.with().with().with(). It feels like it will lead to calling attachSelectors for each of those layers and I wonder if that's a) optimal b) correct

It's correct, and yeah the intermediate selector atoms get GC'd which is slightly wasteful but correct & simple. Also selectors are after-the-fact (they observe the store; they're not part of the store), and we shouldn't add them to storeLogic

[Andarist]

q: related to some of the other questions - why selectors are not part of the StoreConfig?

[davidkpiano]

Keeps it additive so we don't pollute the StoreConfig interface- createStoreConfig and fromStore don't need it at the moment. We can move it in later if we decide to make selectors a broader XState concept maybe?

[sasivarnan]

Thank you for implementing this feature. I am a primary user of the ability to create multiple store instances from a store definition.

Could you confirm if we are planning to use the value returned by createStoreLogic to initialize a local store that is created with useStore? This way we can define the local store in an external file.

[davidkpiano]

Could you confirm if we are planning to use the value returned by createStoreLogic to initialize a local store that is created with useStore? This way we can define the local store in an external file.

Good question; not yet but it should.

[Andarist]

we'd usually only allow a dynamic context to be created based on the provided input. Creating the whole store feels like a divergence from the other APIs