blog/working-with-zustand

[giscus[bot]]

blog/working-with-zustand

Let's dive into some tips for working with Zustand - one of my favourite client state management libraries in React.

https://tkdodo.eu/blog/working-with-zustand

[PeterKwesiAnsah]

Great Article!!!

[rubenbase]

Love your articles 🙌🏼

[mhm13dev]

Really well explained!

[chrissantamaria]

Great writeup! Looking forward to some more in-depth guides :)

I haven't seen the style of putting all actions into a single store object, might try that out. Have you explored defining actions outside of the store? I've found it really effective in some past projects:

• actions can be written outside of createStore which can improve readability (which is generally my main issue with inlined createStore declarations)
• no need to access actions via a store hook, can be imported directly (even outside a React component context!)
• individual action usages can be code-splitted, preventing the central store module from getting too large

The main downside I've found is discoverability (consumers need to find where actions are defined) - still exploring different file patterns to simplify this. Curious what your overall store structure tends to look like!

[TkDodo]

That's pretty neat. I do like my actions as hooks - I don't see this as a downside. It comes in handy if you need to go into depending on zustand/context. I do plan to cover this :)

[timkindberg]

I do prefer actions outside the store as well, mainly because you can Cmd+Click them to jump straight to them. For some reason that doesn't work as well when the actions are in the store.

[vrsttl]

I had issues there, I have tried to implement my first production zustand store using that pattern. I tried to leverage the flexibility, but I noticed that in some setters I ran into race conditions. Turns out, for example, if you want to set up a simple
toggleHasUserApprovedLinkingSites: () => set((state) => ({ hasUserApprovedLinkingSites: !state.hasUserApprovedLinkingSites })) outside of the store, the subscription gets laggy and will not update as it should. Maybe it is specific to my app context, but it was enough of a headache for me to revert back to defining the action inside the store, which works without a hitch.

I really like the actions as a separate object pattern though, and we've just been talking with our colleagues that we will implement most of the advice written here. Very good job & hope to see more of this soon!

[vrsttl]

with that being said, besides actual toggling behavior, all other actions defined outside of the store worked just fine, this was the only use case where the in-store action definition I found superior.

[loia5tqd001]

I think people would appreciate if you push it and open an issue in zustand repo 👀 @vrsttl

[danielolaviobr]

Awesome article!! Congrats

[mtsknn]

I don't use Zustand but these were anyhow excellent tips, thanks. 👍

It provides the bear minimum to get you started (hence the logo)

Heh, I found this funny because the correct phrase is "bare minimum," not "bear minimum." 😃 But seems intentional since Zustand's GitHub page has other funny puns as well:

A small, fast and scalable bearbones state-management solution using simplified flux principles.

(Recipes > Fetching everything)
You can, but bear in mind that it will cause the component to update on every state change!

(Repo description)
🐻 Bear necessities for state management in React

[TkDodo]

Yes that was on purpose 😄

[luizfilho]

awesome!! Nice article!

[mezojm10]

Love this article!

[nadavl]

Awesome article! Love the simplicity 🔥

[JANDA-Developers]

🐻 Adorable bear, cute article

[denisborovikov]

I'm curious about what stops us from creating multiple stores using create, i.e.

const useBearStore = create((set) => ({
  bears: 0,
})

const useFishStore = create((set) => ({
  fish: 0,
})

Instead of having all data in the same store and using slices? Assuming they don't need to interact with each other? Is there any drawbacks?

In Twitter Daishi mentioned that Zustand is primarily designed for a single store.

[marko-hologram]

I thought that tweet meant that Zustand is used to create separate contained stores instead of combining multiple store into some bigger store (e.g. Redux)?

As far as I know, nothing is stopping you from creating multiple stores the way you did it. That's most likely preferred compared to a single big store that holds all state and actions your app has.

[denisborovikov]

This part was unclear to me. It says it can be used with multiple stores but is designed for a single store. Anyway, thanks for the confirmation.

[TkDodo]

I'm also often creating multiple, small stores. It's one of the advantages over redux imo :)

[p6l-richard]

The combine-with-useQuery leaves me wanting for a combination:

• with-tanstack-router-loader-useQuery, and
• with-tanstack-router-action-useMutation

😆

[pauldvu]

I second this

[lgenzelis]

Great article! Simply explained and with great examples!

I'm wondering, what if you had a Forest component and you'd like each instance of that component to have an individual instance of the Bears store? I mean, without losing the ability to just do useBears in any descendants of Forest and get the right number of bears.. 🤔

[pmioduszewski]

Can't wait for the "zustand with context" artictle, This blog is pure gold!

[lgenzelis]

Awesome!! Thanks you both! 😄 ❤️

[ZhengRui]

I have the same problem before, I experimented with named zustand store (https://github.com/ZitySpace/named-zustand-store/blob/master/src/stores/factory.ts) in which I implemented a wrapper to maintain all the stores, the stores can be re-initialized as well. Later in components you can refer to the store by its name. I am not sure my implementation is a good pattern or not, welcome to point out the flaws. Thanks @TkDodo, I actually got to know zustand from your articles about react-query early this year and then I fell in love in zustand :)

[vrsttl]

If I understand the question correctly, I had a similar use case where I wanted to implement a simple store for each picker on a page:

import { create, StoreApi } from "zustand";

export interface PickerStore {
    isOpen: boolean;
    setIsOpen: (isOpen: boolean) => void;
    toggleIsOpen: () => void;
}

// when you add a picker, add a unique key for it here
export const PickerStoreKeys = {
    AcademicTitlePicker: "AcademicTitlePicker",
} as const;

type PickerStoreKeysType = typeof PickerStoreKeys;

type StoreKeyValues<T> = T[keyof T];

export type PickerStoreKey = StoreKeyValues<PickerStoreKeysType>;

// you set up a map to store all stores
const storeMap = new Map<PickerStoreKey, StoreApi<PickerStore>>();

export const usePickerStore = (key: PickerStoreKey): StoreApi<PickerStore> => {
    if (!storeMap.has(key)) {
        const store = create<PickerStore>((set) => ({
            isOpen: false,
            setIsOpen: (isOpen: boolean) => set(() => ({ isOpen })),
            toggleIsOpen: () => set(({ isOpen }) => ({ isOpen: !isOpen })),
        }));
        storeMap.set(key, store);
    }
    return storeMap.get(key) as StoreApi<PickerStore>;
};

Then in your component:

<PickerWithOptionalSearchFilter
    title={title}
    searchText={searchText}
    setSearchText={setSearchText}
    onSelect={setSelectedItem}
    selectedItem={selectedItem}
    storeKey={PickerStoreKeys.AcademicTitlePicker}
    items={items.filter((item) => item.label.toLowerCase().includes(searchText.toLocaleLowerCase())) || []}
/>

And then, finally, in the PickerWithOptionalSearchFilter itself:

const PickerWithOptionalSearchFilter: React.FC<PickerWithOptionalSearchProps> = ({
    isRequired,
    items,
    storeKey,
    isFilterOpen,
    filterOpenHandler,
    disabled = false,
    loading = false,
    loadMore,
    staticDropdownButtonLabel = undefined,
    title,
}) => {
    const store = usePickerStore(storeKey);
    const isFilterOpen = useStore(store, (state) => state.isOpen);
    const setIsFilterOpen = useStore(store, (state) => state.setIsOpen);
    const toggleFilterOpen = useStore(store, (state) => state.toggleIsOpen);
...

We finally went to just have this picker be controlled by its parent, but I think I will remember this pattern for the future. I wonder if context is necessary, or maybe using a Map to store stores is a less complex solution in most contexts?

What do you guys think?

[vrsttl]

edit: the last code block includes import { useStore } from "zustand";

[timkindberg]

Good article! I think the only recommendation I might make is to separate the actions even more, in that you shouldn't even put them into your state in the first place.

export const useFilterStore = create(() => ({
  applied: []
}))

Then you can either use useFilterStore.setState directly in components, just like you would use setState in a casual way...

<Button 
  onClick={() => {
    useFilterStore.setState((state) => ({
      applied: [...state.applied, filter]
    }))
  }}
>
  Add Filter
</Button>

...Or if you want to be more ceremonial about it you can create a named function...

export const addFilter = (filter) =>
  useFilterStore.setState((state) => ({ applied: [...state.applied, filter] })),
}

// Elsewhere
<Button onClick={() => addFilter(filter)}>
  Add Filter
</Button>

I'd written about this in an Github issue as well: pmndrs/zustand#151 (comment)

[timkindberg]

I just saw the comment above about this same suggestion and your reply. Cheers!

[TkDodo]

I think keeping the actions in the store is necessary if you use zustand/context to create multiple versions of your store, scoped to a component tree.

[loia5tqd001]

Like 2 urls /todo/list/1 and todo/list/2 would have 2 separate stores for 2 lists? @TkDodo That sounds genius.

[marko-hologram]

Interesting usage with useQuery there. For some time now the projects I'm working on don't really require external stores like Redux, MobX or Zustand, but maybe I'm not just realizing the benefits of something like Zustand.

Will have to try zustand and react-query a bit more in general. Might solve some issues for me that I don't even realize I have 😄

[ZennerBlade]

One question though

export const useBearActions = () => useBearStore((state) => state.actions)

Wouldn't equality check fail for this as well?
Since state.actions is an object that contains functions, a newer obj would not equal the previous object and the === check would fail?

[TkDodo]

Since state.actions is an object that contains functions, a newer obj would not equal the previous object and the === check would fail?

Theoretically, yes, but when would you create a new actions object? Only if you have an action that actually writes to the action object. I don't know why you should be doing that 😅

[handipriyono]

Thanks for the insight, bro!

[dsacramone]

Zustand allows for a createContext, so you can encapsulate the component in a zustand store. So each has its own instance. Just an fyi.

…

On Tue, Mar 28, 2023, 11:46 PM Attila Veres ***@***.***> wrote: If I understand the question correctly, I had a similar use case where I wanted to implement a simple store for each picker on a page: import { create, StoreApi } from "zustand"; export interface PickerStore { isOpen: boolean; setIsOpen: (isOpen: boolean) => void; toggleIsOpen: () => void; } // when you add a picker, add a unique key for it here export const PickerStoreKeys = { AcademicTitlePicker: "AcademicTitlePicker", } as const; type PickerStoreKeysType = typeof PickerStoreKeys; type StoreKeyValues<T> = T[keyof T]; export type PickerStoreKey = StoreKeyValues<PickerStoreKeysType>; // you set up a map to store all stores const storeMap = new Map<PickerStoreKey, StoreApi<PickerStore>>(); export const usePickerStore = (key: PickerStoreKey): StoreApi<PickerStore> => { if (!storeMap.has(key)) { const store = create<PickerStore>((set) => ({ isOpen: false, setIsOpen: (isOpen: boolean) => set(() => ({ isOpen })), toggleIsOpen: () => set(({ isOpen }) => ({ isOpen: !isOpen })), })); storeMap.set(key, store); } return storeMap.get(key) as StoreApi<PickerStore>; }; Then in your component: <PickerWithOptionalSearchFilter title={title} searchText={searchText} setSearchText={setSearchText} onSelect={setSelectedItem} selectedItem={selectedItem} storeKey={PickerStoreKeys.AcademicTitlePicker} items={items.filter((item) => item.label.toLowerCase().includes(searchText.toLocaleLowerCase())) || []} /> And then, finally, in the PickerWithOptionalSearchFilter itself: const PickerWithOptionalSearchFilter: React.FC<PickerWithOptionalSearchProps> = ({ isRequired, items, storeKey, isFilterOpen, filterOpenHandler, disabled = false, loading = false, loadMore, staticDropdownButtonLabel = undefined, title, }) => { const store = usePickerStore(storeKey); const isFilterOpen = useStore(store, (state) => state.isOpen); const setIsFilterOpen = useStore(store, (state) => state.setIsOpen); const toggleFilterOpen = useStore(store, (state) => state.toggleIsOpen); ... We finally went to just have this picker be controlled by its parent, but I think I will remember this pattern for the future. I wonder if context is necessary, or maybe using a Map to store stores is a less complex solution in most contexts? What do you guys think? — Reply to this email directly, view it on GitHub <#88 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTB7SNHMYJ5KDUC4YO7DBDW6PLE3ANCNFSM6AAAAAASF47QGM> . You are receiving this because you commented.Message ID: ***@***.***>

[vrsttl]

I know, see the last paragraph in my comment - I wonder why using context is superior than just using a Map with named StoreApis?

[vrsttl]

I mean, I don't really see the difference in using useContext to access an instance of this store vs using usePickerStore in my example to do the same, they should both be safe from unnecessary rerenders, and I would argue that one provider less in the app is a net win. On the other hand, I can see that someone would argue that naming the storeKey for each instance is cumbersome, I can subscribe to that. I might not see the big picture, as to what the limitations of using a Map would be in this case.

[pastelmind]

IMO it depends on whether each store instance is incidentally related to the particular component subtree, or is actually owned by said subtree. Does the store have a reason to live even after the subtree is unmounted? Can multiple subtrees use the same instance? If so, each instance is better off put in a Map. (This case is solved by atomFamily() in Recoil, btw) Otherwise, use context to dynamically create and send down stores as needed.

[vrsttl]

Makes sense. So for example, let’s say I were to populate my pickers with API calls stored in store.pickerItems, I would be better off keeping them in a Map, so that they don’t need to be requeried should the component get rebuilt, but if I just have very basic functionality, it would make sense to use context to dismantle the store entirely every time it gets unmounted, is what you’re saying?

If you have a better example, please share, I want to understand the concept as well as possible :)

[peacepostman]

Hello,

Really nice article, really helped me a lot to properly organize my stores.

I have a question regarding a zustand usage.

Admitting a following store

const useStore = create((set, get) => ({
  answers: undefined
  actions: {
    setAnswer: (surveyId, answerId) => {
      set({ answers: { ...get().answers, [surveyId]: answerId } })
    }
}

Does the following subscribe is a good habit or will it have side effects ?

const useAnswer = (surveyId: string) => useStore((state) => surveyId && state.answers && state.answers[surveyId])

Best regards,

[TkDodo]

I think this is just fine 👍

[hedenica]

Hey there, great article!

But I’m still a little confused as to good scenarios to use zustand + query v4.

For example, I have a page where the user gets to filter some stuff (eg: check-in / checkout dates), right now those filter are being passed into the URL by query params.

And there’s some code to push those params into the route, check if the params and the current filters are different in order to update the filters using useState.

I was trying to figure out with in this case, I should use zustand to store the filters or leave it as it is…

I thought for sure since filters can be considerate as global state, I should keep’em there.
But if I can have the filters on the url (its a booking property platform) then those filters are available even if the page is reloaded.

Anyway, still bit confused as to what cases should they be used together.

[TkDodo]

if you have filters in the url, treat the url as your single source of truth. You can access them with useParams() or whatever from your router, and whenever they update, your component will re-render accordingly. No need to copy it anywhere else (local state, zustand, ..)

[myrddral]

Amazing, I grew to like Zustand a lot but this article meant a great leap forward in terms of managing state logic in a clean, readable and easy to nderstand way. I was kinda disappointed that the often stated potential simpleness of the library just came down to a few simple hook examples and very few was clever enough to release the potential of it. Nice one! :)

[PitZza04]

Awesome article <3

[MysteryAchievement]

Great article! Really got me thinking!

You showed an example of combining zustand to filter a query using React Query. What about the inverse - using React Query to fetch, for simplicity, a boolean value to set a value in the store? Any thoughts on what that might look like or if it’s even a good idea?

[TkDodo]

doesn't sound like something that makes a lot of sense to me this way around 😅

[viveleroi]

How can one adhere to the concept of not exporting the store, yet allowing a component to call destroy on "unmount"?

I see no way other than exporting the entire store and calling destroy:

const { destroy } = useMyStore()

useEffect(() => () => {
  destroy()
}), [])

[TkDodo]

you can always build abstractions if you need to, but you can of course always export the store if you want to. It's just my guidelines to not do that, and I'd prefer:

export const useDestroyMyStoreOnUnmount = () => {
  const { destroy } = useMyStore()

  useEffect(() => () => {
    destroy()
  }), [destroy])
}

[viveleroi]

Thanks, I'm told the destroy method is being deprecated soon so it's probably best for me to always use unsubscribe/reset methods, destroy just seemed like a more convenient way to do that.

[viveleroi]

If I have non-React code that needs to use the get/setState methods (like unit tests), would it still make sense to export just the get/setState methods or is it worth it to just export the store?

I've been updating our stores with these and some other suggestions and really like these concepts. However, I'm having troubling applying them to a store we have for a complex date picker/navigation UI. The state data has 6 properties. We export the entire store because multiple properties are used by different components, and we use the setState and getState functions in unit tests.

I could export custom selectors for groups of these properties I guess, but the real question is how best to export the get/setState methods. I can export the entire store of course, but maybe the effort to avoid that in this case isn't worth it?

const initialState: SequenceNavigationState = {
  hasFutureRecords: false,
  hasPastRecords: false,
  isFromCalendar: false,
  isMinTimestamp: false,
  selectedDate: todayInUtc(),
  sequenceDates: []
}

export const useSequenceNavigationStore = createWithEqualityFn<SequenceNavigationState>(() => initialState, shallow)

// Unit tests call, to setup a specific state for use in testing
useSequenceNavigationStore.setState(...)

// React components
const { isFromCalendar, isMinTimestamp, selectedDate } = useSequenceNavigationStore()
// or
const { hasFutureRecords, hasPastRecords, selectedDate, sequenceDates } = useSequenceNavigationStore()

[TkDodo]

sure, there's no hard rule on what you can and cannot do. That stores are global is actually one of the things I don't like that much about zustand, because testing becomes harder. I want to get into this in a follow-up, my preferred approach is to always wrap stores into react context because it makes it easier to isolate, and setup for tests as well.

[viveleroi]

I've been looking into the mocking examples the zustand docs have for testing and feel like it's not explained very well. It's really just a code dump.

Our tests just call setState to put the store into an expected state and then we write tests for the component that uses it. It's probably not ideal, but it works fine from what I've seen. I've been looking for a better explanation on why mocking/context for stores in tests is better because it's unclear just by looking at the code in their docs.

[TommySorensen]

For actions i would always use this approach. This enables me to just import the minimize action directly where i need it.

import { create } from 'zustand';

export const useSomething = create(() => ({
  isMinimized: false
}));

export const minimize = () => useHeaderStore.setState({ isMinimized: true });

[TkDodo]

nice idea - leaving actions out of the store completely. As a bonus, the state now becomes serializable as well.

[furkancakici]

import { create } from 'zustand'
import { useShallow } from 'zustand/react/shallow'

export const useAuthStore = create(set => ({
    user: null,
    setUser: props => set({ user: props }),
    removeUser: () => set({ user: null })
}))

export const useAuth = () =>
    useAuthStore(useShallow(state => ({ user: state.user, setUser: state.setUser, removeUser: state.removeUser })))

// USING

const { setUser, user, removeUser } = useAuth()

[furkancakici]

You can check out the structure I use.

import { create } from 'zustand'
import { useShallow } from 'zustand/react/shallow'

export const useAuthStore = create(set => ({
    user: null,
    setUser: props => set({ user: props }),
    removeUser: () => set({ user: null })
}))

export const useAuth = () =>
    useAuthStore(useShallow(state => ({ user: state.user, setUser: state.setUser, removeUser: state.removeUser })))

// USING

const { setUser, user, removeUser } = useAuth()

[jt6677]

I love putting all the method in actions.FYI, if you use persist middle ware, you would need to partialize.

export interface InitialStateType {

}
export const initialState: InitialStateType = {

}

export interface AppStoreType extends InitialStateType {
  actions: {
   
  };
}

export const useAppStore = create<AppStoreType>()(
  persist(
    (set, get) => ({
      ...initialState,
      actions: {
     
      },
    }),
    {
      name: "appStore",
      getStorage: () => localStorage,
      partialize: (state) =>
        Object.fromEntries(
          Object.keys(initialState).map((key) => [
            key,
            state[key as keyof typeof state],
          ])
        ),
    }
  )
);

[TkDodo]

that should be enough:

partialize: ({ actions, ...rest }) => rest

[jt6677]

OMG of course!....

[yalcinozer]

Hi,
Thanks for the article. I have a middle sized form (has almost 50 input fields). I currently have values in a combination of useState and context but moving to zustand. Can or Should I place zustand in place of useState? I mean setting and reading every input value directly to zustand store. Will there be performance issues thanks? I can use it with combination of useState, but if other way is possible, I want to make it in a simpler way.
Thanks

[TkDodo]

for forms specifically I would recommend react-hook-form:

https://react-hook-form.com/

The forms are uncontrolled per default so it has great perf

[imsandeshpandey]

Great points! I find the treating all actions as a single atom really great, that's such a simple thing to not know yet never thought of it that way.

But I find creating creating serparate hook for individual states a bit of an overkill and too much code for me to be sane haha. So I opted to creating a hook where I can just pass the state name like this:

const fooStore = create<FooStore>((set) => ({
    bar: 10,
    SetBar:....
}))

// Custom Hook
const useFoo = (selector: keyof FooStore) => 
    fooStore(s=> s[selector])


// Implementation 
const bar = useFoo("bar")

This way I can keep my store code relatively small and I also get sweet auto complete and it's easier on the eyes compared to using selectors the default way.