Making get() work more like set() 🤔

[mindplay-dk]

Just a thought but...

const store = createStore((set, get) => ({
  a: 0,
  b: 0,
  reset() {
    set({ a: 0, b: 0 });
  },
  getProduct() {
    return get().a * get().b // 🤨
  },
}))

Calling get() twice. I mean, no, right?

So then:

const store = createStore((set, get) => ({
  a: 0,
  b: 0,
  reset() {
    set({ a: 0, b: 0 });
  },
  getProduct() {
    const { a, b } = get() // 🥱
    return a * b
  },
}))

Still, ugh... the ceremonious unpacking of state before you can use it... ehh.

So then how about:

const store = createStore((set, get) => ({
  a: 0,
  b: 0,
  reset() {
    set({ a: 0, b: 0 });
  },
  getProduct() {
    return get({ a, b }) => a * b // 😏
  },
}))

Wouldn't it be kind of cool if you could pass a selector to get()?

It makes the code look more consistent, doesn't it?

I was honestly kind of surprised this doesn't exist.

Why not? 🙂

[dai-shi]

I don't think the first two cases are too bad.
For the third one, you could write your own middleware. Or, if people want it it can be a third-party library.

[mindplay-dk]

For the third one, you could write your own middleware

so I did that 🙂

tbh this just feels like something that should be built-in.

as we discussed below, I think it's a shame you have to pick between partial encapsulation or no encapsulation.

I want full encapsulation.

I mean, when you see the result here, doesn't it just... make sense?

I dunno... looks way more natural and consistent to me. 🤷‍♂️🙂

[mindplay-dk]

Maybe one reason I'm biased towards encapsulation, is because I also plan on eliminating global state entirely.

I've been working on these utility functions to make it as easy to use providers as it is to use global state:

interface BearStore {
  bears: number;
  increasePopulation(): void;
  removeAllBears(): void;
  validate(minBears: number): string;
}

interface BearStoreInit {
  initialBears: number;
}

export const [BearStoreProvider, useBearStore] =
  createStoreProvider<BearStoreInit>().with(({ initialBears }) =>
    createStore<BearStore>(
      withSelectors((set, get) => ({
        bears: initialBears,
        increasePopulation() {
          set(({ bears }) => ({ bears: bears + 1 }));
        },
        removeAllBears() {
          set({ bears: 0 });
        },
        validate(minBears: number) {
          return get(({ bears }) =>
            bears >= minBears ? "all good" : "not enough bears!"
          );
        },
      }))
    )
  );

what I mean is, this pattern you showed me below:

export const inc = () =>
  useBoundStore.setState((state) => ({ count: state.count + 1 }))

this only actually works with global stores - it doesn't work when the store is context-bound.

and in my opinion, stores should be context bound.

global state gets in the way of testing - and encourages people to write reset actions to clear states (after closing a dialog etc) which I see very much as a symptom of teaching them that a global store is enough.

if we can make it equally practical and ergonomic to "do the right thing", why invite global state? brings nothing but problems. 😌

[dai-shi]

so I did that 🙂

Cool.

tbh this just feels like something that should be built-in.

I'd suggest to make a third-party library if you want to get more feedback.

[dai-shi]

It feels to me that the zustand way is this:

const useFooStore = create((set) => ({
  a: 0,
  b: 0,
  reset() {
    set({ a: 0, b: 0 });
  },
}));
const useFooProduct = () => useFooStore(({ a, b }) => a * b);

[mindplay-dk]

That is definitely the way I'm leaning, yeah. It just feels a bit... disjointed?

Why is it idiomatic to put your state and updates in the store, but derived state has been naughty and needs to leave the class room.

I know it's strictly just vibes and there's no technical reason your model needs to be a single, integral unit, but...

It feels a bit... half-baked? doesn't it? 🤔 or is that just me?? 😄

[dai-shi]

https://github.com/pmndrs/zustand/blob/41fed0fe6f190472bb6b331584cf087546f9df33/docs/guides/practice-with-no-store-actions.md

How do you like this one instead?

---

Anyway, I don't think we make any changes in the near future. But, feel free to continue discussions and experiment with middleware.

[mindplay-dk]

I would prefer to have full encapsulation of states/reads/writes - but at least this approach goes all-in on separation.

I might go with that approach, and rely on the module for encapsulation... since I'll have to anyway. 🙂

[myrj27]

Awesome, thanks!

…

On Fri, 25 Jul 2025, 2:31 am Daishi Kato, ***@***.***> wrote: so I did that <https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbwFBzgYygUwIY0wGhXS10wGUZoCiLSBhEyqQgXzgDMoIQ4AiALwCuAZxjYAdgBNeAbiRIYATzCY4ZTABtMaJgHFMMADwAVAHxwAvIiIAKAJQAuOMbmpDAVVM3hm7UyfeYnhOxnaW5u6OcO5yLHJI7ILiOsAQ4nAA7sAwABbqWjrQwiZeRMDi2cDYGsD8mFABPjBOAArYUNggBvXFtHgMOEwlpgDaAAwAuvhwAOYGTvl+0PpGZmEW5sZIUX2YA7jQJdaoWDCCUOneBtNzMOvmyKioaGmicJjiORJomJIrC75ClAVkcrDYrgUmAB+RpBTAhe5wCSKRGPJ4nAzndI+SHQOBQuA4pZQGy3exhJxkuyuJ4sMLYYRqQF6AwleLo05YuDlSrVWr1K4waYfL7JX4ralEOJIFjycp4KDsbA-OAAIRwUAoVGOcAARhrhE5xIIQPqoDTyhgcD4WhAwIINLhUuJ7E4AG4QYCSGlYEAQN2YACCGg06vawldcA9Xppbr5klINhA5TDUENcGNpvqUVEUHKM1i8he4jeIkwqa1WEsxEGmEMFaYmFKqCyuUWQIjgpuBkRNjRqH14acY0I6MtJBtdodTrS9h16Ka4IQeoNcDp4TgfZXQ+3abgAGo4ABGNd2SXolijp6+-1BkOpiNhftPRfLwdp4enmmoS9EVBxmoEzwJMUwNI0TTNJ8-2vTELlmAwl13Rl1w2aD0XfRlTCsZNxAffE+GqDRZggCBJDgNIkIAQl4OAnAAAzALQGVUbBJDIgASBAcLwgBaJC2D9KsMMoui0Lgc9aSvOk7G2JAgA> 🙂 Cool. tbh this just feels like something that should be built-in. I'd suggest to make a third-party library if you want to get more feedback. — Reply to this email directly, view it on GitHub <#3189 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUF75NSYUPXT25WEKYTPY633KFUFZAVCNFSM6AAAAACCCTFGJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBYGMZDENI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>