blog/zustand-and-react-context

[TkDodo]

Zustand stores a global and don't need React Context - but sometimes, it makes sense to combine them regardless.

https://tkdodo.eu/blog/zustand-and-react-context

[ryanmr]

Thanks for sharing this approach. Having the ability to mock the store out at a react level vs a global or internal level makes a lot of sense for easier testing. I often suggest zustand as an alternative to redux and I'll suggest this too.

By the way, there might be a typo near here, "prop will no be passed".

[TkDodo]

please PR a fix for the typo :)

[andreaskromann]

Isn't this exactly what is documented in the zustand readme file here: https://github.com/pmndrs/zustand?tab=readme-ov-file#react-context

[TkDodo]

Yes - I wrote some of those docs for v4 iirc 😅. Judging from the feedback I'm getting, we should make this more prominent in the docs. I'm also trying to outline in which situations you'd want to combine it with React context rather than just describing how it works technically.

[MathieuFedrigo]

Cool, thanks 👍

Is there a reason why you shouldn't use the regular create with this approach like so?

import { create } from 'zustand'

const [useStore] = useState(() => create(...)) // Provider

// Usage
const useBearStore = (selector) => {
  const useStore = useContext(BearStoreContext)
  if (!useStore) throw new Error('Missing BearStoreProvider')
  return useStore(selector)
}

[TkDodo]

that would put a custom hook into context, not sure what the advantage here would be?

create from zustand is literally:

• createStore
• pass the result to useStore

https://github.com/pmndrs/zustand/blob/e00c69f82b9db65dc13b88563cc2f713f6bb2320/src/react.ts#L113-L117

But yes, I think it would work, too.

[netgfx]

Thanks for this approach. Could we initialize the provider with the result of an async operation like fetching data from an API so they are initially available to the children? And if so, could this also solve hydration problems if we only render children once the data are available?

[TkDodo]

well you can run a query, then suspend or show a Loader until data is available, and only then render your custom Provider with the initial values, sure :)

it would bypass hydration errors because on the server, only a loading spinner would be rendered ...

[vincent-rcp]

Curious, where would you put the API call if it's data for the application level? Would you put another provider around the BearStoreProvider?

Great article btw!

[TkDodo]

This is all hypothetical because I wouldn’t put data from an async operation into a client side state manager - that’s what we have useQuery for.

[hassan-kamel]

https://github.com/hassan-kamel/zustand-with-async-initialization-example

this is a vibe-coded example 😂

[Thiagolino8]

I work on a social network and we use this pattern a lot so that each item in the feed has its own store, the biggest difference being the use of create instead of createStore

I don't quite understand the reason for this difference in your example, as it will be turned into a hook anyway using useStore

[TkDodo]

I got this right from the zustand docs :)

https://docs.pmnd.rs/zustand/previous-versions/zustand-v3-create-context#migration

[andrewdoro]

Let's say that the initialBears value could change. This could be as a result of a new fetch request happening in the component tree. How should we handle this to make sure the values are synced? Do we need an useEffect to reset the store values?

[andrewdoro]

This can happen quite often if you use Next.js and call router.refresh() for new data. (component tree will not be unmounted, just re-rendered)

[TkDodo]

data should have a single source of truth, thus it shouldn't need syncing. If the initialBears come from an API endpoint, why would you need to copy it to zustand. Also, consider the following example:

• initialBears is 0, so bears is also 0.
• user increases population by 5, so bears is 5.
• initialBears changes to 1.

At that point, do you really want to overwrite the user selection and set bears:1 ?

[andrewdoro]

Yes, that's true in that case, it wouldn't really make sense to reset bears change.

My case was more related to creator-viewer flow. In this example we can imagine two users:

• Creator: that has access to the bear component edit
• Viewer: without editing access and only sees the bear number

const Bears = ({ editable }: { editable: boolean }) => {
  const bears = useBearStore((state) => state.bears)

  return (
    <div>
      {/* // increase bear population */}
      {editable && <IncreasePopulationButton />}

      {/* // save bear population */}
      {editable && <SaveButton />}

      <p>{bears}</p>
    </div>
  )
}

A common flow that might happen:

• Admin - changes initialBears to 1. Saves it to DB.
• Viewer - enters the page and sees the same component with initialBears set to 1.
• Admin - changes initialBears value
• Viewer - Fetch request happening again for the client, because of polling or just window refocus. initialBears still set to 1 (I want in this case to have the value reset by the new value coming from API)

I know we can separate the view component and edit component so we don't need zustand on the client side. This would result in the source of truth being the API for the client. But this comes with a drawback...

• In most cases, we use zustand or context-like approach to avoid prop driling and we usually have more states than just a single value.
• When using React-Query or other fetching libraries we can have custom hooks that subscribe to QueryClientProvider cache as the source of truth. (instead of a store)

The problem arises when you have highly interactive UI's (let's say a chart with a lot of filters) and you don't want to duplicate each component logic:

• a creator chart that changes the filters and updates the db
• a client chart that only show the data based on the default values coming from the db

In this case, it's much simpler to just have the chart filters as a source of truth and just reset it when a default value changes.

//I still think you are right with the single source of truth (so should be better to have two components), this was just a minor inconvenience

[SeanCassiere]

What does the typescript side of this look like?

My best approximation of this would be this? Anyone have a cleaner approach here?

function createBearStore(initialBears: number) {
  return createStore((set) => ({
      bears: initialBears,
      actions: {
        increasePopulation: (by) =>
          set((state) => ({ bears: state.bears + by })),
        removeAllBears: () => set({ bears: 0 }),
      },
    }))
}

type BearStore = ReturnType<typeof createBearStore>

const BearStoreContext = React.createContext<BearStore | null>(null)

[andrewdoro]

hey this implementation should help you

https://x.com/mattpocockuk/status/1780865485325979685?s=46&t=cmQVCdpY7_bVoOftn8NIcg

[bryanprimus]

i created my own version that is fully type safe

https://gist.github.com/bryanltobing/e09cb4bb110c4d10cefde665b572d899

[markbenliyan]

Alternatively you could just use the type from Zustand and then ur type. So

const UserActionsContext = createContext<StoreApi<UserActions> | null>(null)

Or a full example here

type UserActions = {
  currentSpacingAdjustment: keyof ResumeSpacing | ''
  hoveredTemplate: TemplateName | null
  actions: {
    setCurrentSpacingAdjustment: (currentSpacingAdjustment: keyof ResumeSpacing | '') => void
    setHoveredTemplate: (template: TemplateName | null) => void
  }
}

const UserActionsContext = createContext<StoreApi<UserActions> | null>(null)

const UserActionsProvider = ({ children }: { children: ReactNode }) => {
  const [store] = useState(() =>
    createStore<UserActions>(set => ({
      currentSpacingAdjustment: '',
      hoveredTemplate: null,
      actions: {
        setCurrentSpacingAdjustment: (currentSpacingAdjustment: keyof ResumeSpacing | '') =>
          set({ currentSpacingAdjustment }),
        setHoveredTemplate: (template: TemplateName | null) => set({ hoveredTemplate: template }),
      },
    }))
  )
  return <UserActionsContext.Provider value={store}>{children}</UserActionsContext.Provider>
}

const useUserActionsContext = () => {
  const context = useContext(UserActionsContext)
  if (!context) {
    throw new Error('useUserActionsContext must be used within a UserActionsProvider')
  }
  return context
}

[aboveyunhai]

What happen to both the React Context and Zustand store when the <Provider /> is destroyed along with the components. (like unmount or route change).
Automatically clean the data and garbage collected as expect?

[TkDodo]

yes, just like with any other state inside a react component that gets unmounted.

[john093e]

How to use this with slices pattern ?
Many thanks for this great article

[TkDodo]

I've never used the slices pattern 🤷

[denniscual]

However, we have to make sure that the creation of the store only happens once. We can do this with refs, but I prefer useState for that. I have a separate blogpost on that topic if you want to know why.

Let say if React Forget is already been implemented, do you think initializing it with useState is still the approach for referential stability?

[denniscual]

Great blog btw!

[TkDodo]

yes because React Forget will add useMemo, and memo is not guaranteed to never be re-evaluated. See:

• https://tkdodo.eu/blog/use-state-for-one-time-initializations

[LuiGeeDev]

I first used this pattern when I first started using zustand in Next.js. It was annoying at first, but as I continued to use it, I realized that it's a good pattern because you can adjust the scope of the store with Context. It can be applied in various ways, such as having a Context at the top to store the data needed throughout the app, or using a Context on a page to use the data needed only on the page without worrying about initializing the store.

[GalindoSVQ]

I like the idea, I have not been able to implement it in using tankstack router file-based.

[mvolonnino]

With this approach - do you lose the ability to use the zustand store outside react comments?

Say I have functions that run not within a react component, that utilize the setState &getState methods on a normal create store

function updateStateOutsideCompScope(update) {
   useZustandStoreContext.setState(update)
}

From my quick understanding - since this is being utilized within React Context - everything would need to be within a React Component?

[TkDodo]

yes

[mvolonnino]

Figured as much - thank you! Great article 🔥

[Darren120]

typescript implementation ? :3

[zeorin]

I've used the Zustand + Context approach to improve performance in naive state management implementations that just passed a state object into the provider, causing all consumers to re-render for any change. I also added react-tracked's createTrackedSelector so that the consumers didn't have to change how they were accessing the state: createTrackedSelector will dynamically create a Zustand selector based on usage tracking (like what React Query does with query result objects).

I've had rendering perf go from 150+ms per keystroke to ±6ms on a project that is still using Formik, for example, with this approach. It works because now only the field that is being interacted with re-renders on a keystroke, instead of every single field.

[TkDodo]

I've used the Zustand + Context approach to improve performance in naive state management implementations that just passed a state object into the provider, causing all consumers to re-render for any change

not sure I understand this. With zustand + context, you put the static store instance that never changes into context. What creates the re-rendering of components is the zustand subscription, not the react context

[zeorin]

Yes indeed. The re-renders for all consumers was the naive implementation without Zustand.

With Zustand + React Tracked I was able to get the improvement without having to change the consumers, apart from importing their hook (e.g. useField) from a different file. They were able to keep using it the same way.

[ashishsurya]

How to type the selector in

const useBearStore = (selector) => {
  const store = React.useContext(BearStoreContext)
  if (!store) {
    throw new Error('Missing BearStoreProvider')
  }
  return useStore(store, selector)
}

[bryanprimus]

it might be depends on your implementation. but check this out https://gist.github.com/bryanltobing/e09cb4bb110c4d10cefde665b572d899#file-viewmodelzustand-tsx-L22-L27 in case it suits your use case

[Musta-Pollo]

Didn't work for me. I ended up using interfaces of my slices:

const useAppStore = <T, U>(
  selector: (state: DataSlice & SearchSettingsSlice) => U
): U => {
...

[mindmind]

Thanks a lot for the proposed solution! Will try in my next project

[laozhu]

Great article for zustand best practice, learnt lots from it, thanks for sharing.
I have a question maybe not related to this article, it's about using zustand with react-query, if I have to fetch remote data as initial store values, Is saving remote data in useEffect of Provider a good way?

[TkDodo]

it's not. I have a couple of articles on this topic:

• https://tkdodo.eu/blog/react-query-as-a-state-manager
• https://tkdodo.eu/blog/react-query-and-forms

[Jlassi-ABK]

Thank you TkDodo, your code is awesome and helped me a lot!

[aaron-mota]

Here's how I'm currently using it in TypeScript with the slices pattern. I opted for the create instead of createStore simply because I could reuse the setup I have for my "default" global zustand store (slices pattern).

store.ts (React Context + Zustand; slices pattern)

// store.ts

import * as itemA from './slices/itemA/slice.ts'
// import * as itemB from './slices/itemB/slice.ts'
// ...import more slices

export type TStore = itemA.TSlice; // itemA.TSlice & itemB.TSlice & itemA.TSlice... (imported slices)

// context
interface ContextProps extends StoreApi<TStore> {} // this line isn't necessary (ContextProps alias), but I'm keeping consistency with my other standard React Context file setups that exist in my project
const Context = createContext<ContextProps | null>(null);

// context provider (makes context accessible to children)
interface ProviderProps {
  children: React.ReactNode;
  // initialData: Partial<TStore>; // optional (store can be initialized with data)
}
export const ContextProviderItems = ({ children }: ProviderProps) => {
  const [store] = useState(() =>
    create<TStore>()((...a) => ({
      ...itemA.slice(...a),
      // ...add more slices
    }))
  );

  return (
    <Context.Provider value={store}>
      {children}
      <DevToolsZustand />
    </Context.Provider>
  );
};

export function useStoreItems<T>(selector: (state: TStore) => T): T {
  const store = useContext(Context);
  if (!store) {
    throw new Error('useStoreItems must be used within a ContextProviderItems');
  }
  return useStore(store, selector);
}

if interested, my standard "generic" slices files (I use the folder name to determine which slice it is, similar to file-based routing with NextJS/Expo router):

slices.ts

// store.ts

import * as itemA from './slices/itemA/slice.ts'
// import * as itemB from './slices/itemB/slice.ts'
// ...import more slices

export type TStore = itemA.TSlice; // itemA.TSlice & itemB.TSlice & itemA.TSlice... (imported slices)

// context
interface ContextProps extends StoreApi<TStore> {} // this line isn't necessary (ContextProps alias), but I'm keeping consistency with my other standard React Context file setups that exist in my project
const Context = createContext<ContextProps | null>(null);

// context provider (makes context accessible to children)
interface ProviderProps {
  children: React.ReactNode;
  // initialData: Partial<TStore>; // optional (store can be initialized with data)
}
export const ContextProviderItems = ({ children }: ProviderProps) => {
  const [store] = useState(() =>
    create<TStore>()((...a) => ({
      ...itemA.slice(...a),
      // ...add more slices
    }))
  );

  return (
    <Context.Provider value={store}>
      {children}
      <DevToolsZustand />
    </Context.Provider>
  );
};

export function useStoreItems<T>(selector: (state: TStore) => T): T {
  const store = useContext(Context);
  if (!store) {
    throw new Error('useStoreItems must be used within a ContextProviderItems');
  }
  return useStore(store, selector);
}

[aaron-mota]

Let me try that again...

if interested, my standard "generic" slices files (I use the folder name to determine which slice it is, similar to file-based routing with NextJS/Expo router):

slices.ts

// slice.ts
// Note: you will get errors in a "slice.ts" file until you add it type to the store in "store.ts"

export interface TSlice {
 // ...
}

export const slice: StateCreator<TStore, [], [], TSlice> = (set) => ({
  // ...
});

[361183106]

Thank you for sharing. I also have something to share that I would like to tell you about, if you need to check the time in different cities, you can visit https://timeis24.com Current local time

[tomashaddad]

Thank you for the article! I'm a bit confused about how the recommendation to "create multiple, small stores on a per-feature basis" is meant to fit in here (which I agree with, despite what Zustand recommends). Should you write all of this boilerplate and create a Provider for every store you want to pass props to or scope to a particular subtree? This pattern seems mandatory (?) for Next.js applications but I can see it getting messy.

[TkDodo]

Not every store needs to be put into a context, and between server state and url state, there really aren’t a lot of things that I’d want to put in a global client store, so this isn’t a problem I’ve been facing yet.

[Haraldson]

I’ve been following this guide, and hit a bump in the road that I find super weird;

const EditComponent = () => {
    const increasePopulation = useBearStore(state => state.increasePopulation)
    return <button onClick={() => increasePopulation(1)}>Add 1</button>
}

const ViewComponent = () => {
    const bears = useBearStore(state => state.bears)
    return <>There are {bears} bears</>
}

These selectors will override each other, causing the selector used in whichever component that mounts last to also be used by all others?

Any pointers much appreciated!

[TkDodo]

That shouldn't be the case. Can you try to make a standalone reproduction?

[suryaashish-tyke]

Can i do this

const Parent = () => {
	const [store] = useState(() => createStore());

	return (
		<Provider value={store}>
			<Child />
		</Provider>
	);
};

const Child = () => {
	const store = useContext();

	console.log(store.getState());

	return <div>child</div>;
};

[TkDodo]

Child is not subscribed to the store then, because getState() is not a subscription. So Child won’t re-render if something in the store changes.

[suryaashish-tyke]

I can do something like this in the child component right

const {} = store()

[suryaashish-tyke]

because getState() is not a subscription. So Child won’t re-render if something in the store changes.

i have used this for example

[TkDodo]

no, you have to subscribe with useStore

[suryaashish-tyke]

Ok got it, thank you for clearing

[jophy-ye]

Since it’s preferable to create multiple small stores for different purposes, how does that work with React context?

A way I can think of is to create 1 context per store, but that leads to potentially nesting many layers of providers.

[suryaashish-tyke]

This is not for global-state, this will be helpful when you want part of UI has some complex state. example like a Multi step form

[jophy-ye]

Sorry I’m afraid I don’t understand what you mean. I do want only part of my application (non-global indeed) have more than 1 Zustand store. What do you mean by “this is not for global-state?

[ashishsurya]

Only for Global state you have to wrap your app with many providers.

[jophy-ye]

Ok, thanks. I just wanted to clarify that the best way is to nest printers like

<A.Provider value={...}>
  <B.Provider value={...}>
    <C.Provider value={...}>
      <D.Provider value={...}>
        ...
      </D.Provider>
    </C.Provider>
  </B.Provider>
</A.Provider>

[TkDodo]

If I have multiple stores for different states, and I want to put each of them into context, then yes, a separate Provider is needed. But once I reach a tree like you’ve shown, the question is why are they all separate states if the children all need access to everything ...

[Faithfinder]

Do you think using zustand in place of a local useState, purely for persistence middleware, is a good idea? I'm looking for ways to persist tanstack table states for users.

Simple useLocalStorage is kinda an option, but I'm afraid of footguns with race conditions if I make complex state, and don't like key proliferation if it's "separate key for pagination, separate key for filtering etc" schema

[gjstreicher]

Defining the store inside the Provider means that you can only access it within React.

If you need to call store.getState() or store.setState() outside of a React component then you won't be able to unless you pull the store definition (call to createStore) out of the Provider.

Pulling it out of the Provider means the Provider cannot initialize the state. This really shouldn't be an issue because you can just define the store in an ESM module that allows for top-level await (or alternatively in an async function that you can call before initializing React).

This means you can make an async fetch call to a backend, or other service, to get the initial state to initialize the store with, if at all necessary.

Where would you possibly want to access the store outside of React?

You might want to trigger changes to store state on events not controlled by React (eg. window popstate or window resize events).

You might want to update the store within a React Router loader function, etc.

These kinds of scenarios require you to have access to the store outside of React.

[gjstreicher]

Something I'm working on currently is to have navigation sent along with data from endpoints. You can think of this as a simplified version of HATEAOS.

The navigation should populate a breadcrumb trail. Instead of recreating the same breadcrumb component on all React Router pages, I'd much rather just put one component in a React Router layout and have it read directly from a store.

Though, then I'd have to write to the given store from the React Router loaders.

I'm still in the process of implementing this, but I like that you've shown a way to use Zustand along with React Context, which I'd like to do when solving for this use case.

[gjstreicher]

Correction, it's called HATEOAS.

Link: https://en.wikipedia.org/wiki/HATEOAS

[gjstreicher]

I further need access to the store to depopulate it when the window event of popstate is called, which is triggered when the user selects the back button in the browser or when they manually change the URL in the browser.

[gjstreicher]

I could add the eventListener on window within a useEffect in a top-level component, but why should I have to do bother with that at all?

[gjstreicher]

I've implemented a dummy version of what you've suggested.

One improvement could be to make the selector passed to the useBearStore hook optional and to substitute a default selector if none was passed.
The default can just be (state) => state.

[GustavoHenriqueP]

I love this article and I keep coming back to it to refresh my memory on Zustand with Context API. Thanks for sharing this approach!

I would like to ask you for an opinion. In stores that would truly be global, i.e a theme store, do you think this approach is still valid and advantageous?
I'm in doubt whether to transform my global contexts into Zustand stores. "In the name of consistency" I was thinking about following this approach in them too.

[TkDodo]

it’s probably not needed.

[dandresjs]

how this works when updating the state?

[TkDodo]

sorry I don’t understand the question 🤷‍♂️

[ahmed-abohmaid]

Thanks a lot! This is very helpful.
I have written a LinkedIn post sharing your article here: https://www.linkedin.com/posts/ahmed-abohmaid_%D8%A7%D8%BA%D9%84%D8%A8%D9%86%D8%A7-%D8%A8%D9%8A%D8%AD%D8%A8-%D9%8A%D8%B3%D8%AA%D8%AE%D8%AF%D9%85-zustand-%D8%A8%D8%B3-%D9%87%D9%84-%D8%AC%D8%B1%D8%A8%D8%AA-%D9%82%D8%A8%D9%84-activity-7452305199173533696-S5Gu?utm_source=share&utm_medium=member_desktop&rcm=ACoAADgY3jYB4GOJDcfLlAuEtLbr6e_tPHnzr1I