{"id":6584,"date":"2025-07-21T14:56:35","date_gmt":"2025-07-21T19:56:35","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=6584"},"modified":"2025-07-21T14:56:36","modified_gmt":"2025-07-21T19:56:36","slug":"introducing-zustand","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/introducing-zustand\/","title":{"rendered":"Introducing Zustand (State Management)"},"content":{"rendered":"\n

Zustand<\/a> is a minimal, but fun and effective state management library. It’s somewhat weird for me to write an introductory blog post on a tool that’s over 5 years old and pretty popular. But it’s popular for a reason, and there are almost certainly more developers who aren’t familiar with it than are. So if you’re in the former group, hopefully this post will be the concise and impactful introduction you didn’t know you needed.<\/p>\n\n\n\n

The code for everything in this post is on my GitHub repo<\/a>.<\/p>\n\n\n\n

Getting Started<\/h2>\n\n\n\n

We\u2019ll look at a toy task management app that does minimal work so we can focus on state management. It shows a (static) list of tasks, a button to add a new task, a heading showing the number of tasks, and a component to change the UI view between three options.<\/p>\n\n\n\n

Moreover, the same app was written 3 times, once using vanilla React context for state, once using Zustand simply but non-idiomatically, and then a third version using Zustand more properly, so we can see some of the performance benefits it offers.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Each of the three apps is identical, except for the label above the Add New Task<\/strong> button.<\/p>\n\n\n\n

Each app is broken down more or less identically as so.<\/p>\n\n\n

function<\/span> App<\/span>(<\/span>) <\/span>{\n  console<\/span>.log(\"Rendering App\"<\/span>);\n\n  return<\/span> (\n    <div<\/span> className<\/span>=\"m-5 p-5 flex flex-col gap-2\"<\/span>><\/span>\n      <VanillaLabel<\/span> \/><\/span>\n      <AddNewTask<\/span> \/><\/span>\n      <TasksCount<\/span> \/><\/span>\n      <TasksHeader<\/span> \/><\/span>\n      <Filter<\/span> \/><\/span>\n      <TasksBody<\/span> \/><\/span>\n    <\/div<\/span>><\/span><\/span>\n  );\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
It’s probably more components than needed, but it’ll help us inspect render performance.<\/p>\n\n\n\n
The state we need<\/h3>\n\n\n\n
Our state payload for this app will include an array of tasks, a method to update the tasks, the current UI view being displayed, a function to update it, and a current filter, with, of course, a method to update it.<\/p>\n\n\n\n
Those values can all be declared as various pieces of state, and then passed down the component tree as needed. This is simple and it works, but the excessive amount of prop passing, often referred to as “prop drilling,” can get annoying pretty quickly. There are many ways to avoid this, from state management libraries like Zustand, Redux, and MobX, to the regular old React context.<\/p>\n\n\n\n
In this post, we’ll first explore what this looks like using React context, and then we’ll examine how Zustand can simplify things while improving performance in the process.<\/p>\n\n\n\n
The Vanilla Version<\/h2>\n\n\n\n
There’s a very good argument to be made that React’s context feature was not designed to be a state management library, but that hasn’t stopped many devs from trying. To avoid excessive prop drilling while minimizing external dependencies, developers will often store the state required for a specific part of their UI in context and access it lower in the component tree as needed.<\/p>\n\n\n\n
Our app has its entire state stored like this, but that’s just a product of how unrealistically small it is.<\/p>\n\n\n\n
Let’s get started. First, we have to declare our context<\/p>\n\n\n
const<\/span> TasksContext = createContext<TasksState>(null<\/span> as<\/span> any<\/span>);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then we need a component<\/em> that renders a Provider<\/em> for that context, while declaring, and then passing in the actual state<\/p>\n\n\n
export<\/span> const<\/span> TasksProvider = ({ children<\/span> }: { children<\/span>: ReactNode<\/span> }<\/span>) =><\/span> {\n  console<\/span>.log(\"Rendering TasksProvider\"<\/span>);\n\n  const<\/span> [tasks, setTasks] = useState<Task[]>(dummyTasks);\n  const<\/span> [currentView, setCurrentView] = useState<TasksView>(\"list\"<\/span>);\n  const<\/span> [currentFilter, setCurrentFilter] = useState<string<\/span>>(\"\"<\/span>);\n\n  const<\/span> value: TasksState = {\n    tasks,\n    setTasks,\n    currentView,\n    setCurrentView,\n    currentFilter,\n    setCurrentFilter,\n  };\n\n  return<\/span> <TasksContext.Provider value={value}>{children}<\/TasksContext.Provider>;\n};<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
The logging console.log(\"Rendering TasksProvider\");<\/code> is present in every component in all versions of this app, so we can inspect re-renders.<\/p>\n\n\n\n
Notice how we have to declare each piece of state with useState<\/code> (or useReducer<\/code>)<\/p>\n\n\n
const<\/span> [tasks, setTasks] = useState<Task[]>(dummyTasks);\nconst<\/span> [currentView, setCurrentView] = useState<TasksView>(\"list\"<\/span>);\nconst<\/span> [currentFilter, setCurrentFilter] = useState<string<\/span>>(\"\"<\/span>);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
and then splice it together in our big state payload, and then render our context provider<\/p>\n\n\n
const<\/span> value: TasksState = {\n  tasks,\n  setTasks,\n  currentView,\n  setCurrentView,\n  currentFilter,\n  setCurrentFilter,\n};\n\nreturn<\/span> <TasksContext.Provider value={value}>{children}<\/TasksContext.Provider>;<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
To get<\/em> the current context value in a component that wants to use it, we call the useContext<\/code> hook, and pass in the context object we declared above. To simplify this, it’s not uncommon to build a simple hook for just this purpose.<\/p>\n\n\n
export<\/span> const<\/span> useTasksContext = ()<\/span> =><\/span> {\n  return<\/span> useContext(TasksContext);\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Now components can grab whatever slice of state they need.<\/p>\n\n\n
const<\/span> { currentView, tasks, currentFilter } = useTasksContext();<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
What’s the problem?<\/h3>\n\n\n\n
This code is fine<\/em>. It’s simple enough. And it works. I’ll be honest, though, as someone who works with code like this a lot, the boilerplate can become annoying pretty quickly. We have to declare each piece of state with the normal React primitives (useState, useReducer), and then also integrate it into our context payload (and typings). It’s not the worst thing to deal with; it’s just annoying.<\/p>\n\n\n\n
Another downside of this code is that all<\/em> consumers of this context will always rerender anytime any<\/em> part of the context changes, even if that particular component is not using the part of the context that just changed. We can see that with the logging that’s in these components.<\/p>\n\n\n\n
For example, changing the current UI view rerenders everything, even though only the task header, and task body read that state<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Introducing Zustand<\/h2>\n\n\n\n
Zustand is a minimal but powerful state management library. To create state, Zustand gives you a create<\/code> method<\/p>\n\n\n
import<\/span> { create } from<\/span> \"zustand\"<\/span>;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
It’s easier to show this than to describe it.<\/p>\n\n\n
export<\/span> const<\/span> useTasksStore = create<TasksState>(set<\/span> =><\/span> ({\n  tasks,\n  setTasks: (arg<\/span>: Task<\/span>[] | ((tasks<\/span>: Task<\/span>[]<\/span>) =><\/span> Task[])) => {\n    set<\/span>(state<\/span> =><\/span> {\n      return<\/span> {\n        tasks: typeof<\/span> arg === \"function\"<\/span> ? arg(state.tasks) : arg,\n      };\n    });\n  },\n  currentView: \"list\"<\/span>,\n  setCurrentView: (newView<\/span>: TasksView<\/span><\/span>) =><\/span> set<\/span>({ currentView: newView }),\n  currentFilter: \"\"<\/span>,\n  setCurrentFilter: (newFilter<\/span>: string<\/span><\/span>) =><\/span> set<\/span>({ currentFilter: newFilter }),\n}));<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We pass a function to create<\/code> and return our state. Just like that. Simple and humble. The function we pass also takes an argument, which I’ve called set<\/code>. The result of the create<\/code> function, which I’ve named useTasksStore<\/code> here, will be a React hook that you use to read<\/em> your state.<\/p>\n\n\n\n
Updating state<\/h3>\n\n\n\n
Updating our state couldn’t be simpler. The set<\/code> function we see above is how we do that. Notice our updating functions like this:<\/p>\n\n\n
setCurrentView: (newView<\/span>: TasksView<\/span><\/span>) =><\/span> set<\/span>({ currentView: newView }),<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
By default set<\/code> will take what we return, and integrate it<\/em> into the state that’s already there. So we can return the pieces that have changed, and Zustand will handle the update.<\/p>\n\n\n\n
Naturally, there’s an override: if we pass true<\/code> for the second argument to set<\/code>, then what we return will overwrite the existing state in its entirety. <\/p>\n\n\n
clear: ()<\/span> =><\/span> set<\/span>({}, true<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The above would wipe our state, and replace it with an empty object; use this cautiously!<\/p>\n\n\n\n
Reading our state<\/h3>\n\n\n\n
To read our state in the components which need it, we call the hook that was returned from create<\/code>, which would be useTasksStore<\/code> from above. We could<\/em> read our state in the same way we read our context above<\/p>\n\n\n\n
This is not the best way to use Zustand. Keep reading for a better way to use this API.<\/p>\n\n\n
const<\/span> { currentView, tasks, currentFilter } = useTasksStore();<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
This will work and behave exactly like our context example before.<\/p>\n\n\n\n
This means changing the current UI view will again re-render all components that read anything<\/em> from the Zustand store, whether related to this piece of state, or not.<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
The Correct Way to Read State<\/h2>\n\n\n\n
It’s easy to miss in the docs the first time you read them, but when reading from your Zustand store, you shouldn’t do this:<\/p>\n\n\n
const<\/span> { yourFields } = useTasksStore();<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Zustand is well optimized, and will cause the component with the call to useTasksStore<\/code> to only re-render when the result<\/em> of the hook call changes. By default, it returns an object with your entire state. And when you change any piece of your state, the surrounding object will have to be recreated by Zustand, and will no longer match.<\/p>\n\n\n\n
Instead, you should pass a selector argument into useTasksStore<\/code>, in order to select<\/em> the piece of state you want. The simplest usage would look like this<\/p>\n\n\n
const<\/span> currentView = useTasksStore(state<\/span> =><\/span> state.currentView);\nconst<\/span> tasks = useTasksStore(state<\/span> =><\/span> state.tasks);\nconst<\/span> currentFilter = useTasksStore(state<\/span> =><\/span> state.currentFilter);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Now our call returns only the currentView<\/code> value in the first line, or our tasks<\/code> array, or currentFilter<\/code> in our second and third lines, respectively.<\/p>\n\n\n\n
The value returned for currentView<\/code> will only be different if you’ve changed<\/em> that state value, and so on with tasks<\/code>, and currentFilter<\/code>. That means if none<\/em> of these values have changed, then this component will not rerender, even if other<\/em> values in our Zustand store have changed.<\/p>\n\n\n\n
If you don’t like having those multiple calls, you’re free to use Zustand’s useShallow<\/code> helper<\/p>\n\n\n
import<\/span> { useShallow } from<\/span> \"zustand\/react\/shallow\"<\/span>;\n\n\/\/ ...<\/span>\nconst<\/span> { tasks, setTasks } = useTasksStore(\n  useShallow(state<\/span> =><\/span> ({\n    tasks<\/span>: state.tasks,\n    setTasks<\/span>: state.setTasks,\n  }))\n);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The useShallow<\/code> hook lets us return an object with the state we want, and will trigger a rerender only if a shallow check on the properties in this object change.<\/p>\n\n\n\n
If you want to save a few lines of code, you’re also free to return an array with useShallow<\/code>.<\/p>\n\n\n
const<\/span> [tasks, setTasks] = useTasksStore(useShallow(state<\/span> =><\/span> [state.tasks, state.setTasks]));<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
This does the same thing.<\/p>\n\n\n\n
The Zustand-optimized version of the app only uses the useTasksStore<\/code> hook with a selector function, which means we can observe our improved re-rendering.<\/p>\n\n\n\n
Changing the current UI view will only rerender the components that use the ui view part of the state.<\/p>\n\n\n
\n
\"Console<\/figure>\n<\/div>\n\n\n
For a trivial app like this, it probably won’t matter, but for a large app at scale, this can be beneficial, especially for users on slower devices.<\/p>\n\n\n\n
Odds & Ends<\/h2>\n\n\n\n
The full Zustand docs are here<\/a>. Zustand has a delightfully small surface area, so I’d urge you to just read the docs if you’re curious.<\/p>\n\n\n\n
That being said, there are a few features worth noting here.<\/p>\n\n\n\n
Async friendly<\/h3>\n\n\n\n
Zustand doesn’t care where or when the set<\/code> function is called. You’re free to have async methods in your store, which call set<\/code> after a fetch.<\/p>\n\n\n\n
The docs offer this example:<\/p>\n\n\n
const<\/span> useFishStore = create(set<\/span> =><\/span> ({\n  fishies<\/span>: {},\n  fetch<\/span>: async<\/span> pond => {\n    const<\/span> response = await<\/span> fetch(pond);\n    set<\/span>({ fishies: await<\/span> response.json() });\n  },\n}));<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Reading state inside your store, but outside of set<\/code><\/h3>\n\n\n\n
We already know that we can call set(oldState => newState)<\/code>, but what if we need (or just want) to read the current<\/em> state inside one of our actions, unrelated to an update?<\/p>\n\n\n\n
It turns out create<\/code> also has a second argument, get<\/code>, that you can use for this very purpose<\/p>\n\n\n
export<\/span> const<\/span> useTasksStore = create<TasksState>((set<\/span>, get<\/span><\/span>) =><\/span> ({<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
And now you can do something like this<\/p>\n\n\n
logOddTasks: ()<\/span> =><\/span> {\n  const<\/span> oddTasks = get<\/span>().tasks.filter((_, index) => index % 2 === 0);\n  console.log({ oddTasks: oddTasks });\n},<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The first line grabs a piece of state, completely detached from any updates.<\/p>\n\n\n\n
Reading state outside of React components<\/h3>\n\n\n\n
Zustand gives you back a React hook<\/em> from create<\/code>. But what if you want to read your state outside of a React component? Zustand attaches a getState()<\/code> method directly onto your hook, which you can call anywhere.<\/p>\n\n\n
useEffect(()<\/span> =><\/span> {\n  setTimeout(()<\/span> =><\/span> {\n    console<\/span>.log(\"Can't call a hook here\"<\/span>);\n    const<\/span> tasks = useTasksStore.getState().tasks;\n    console<\/span>.log({ tasks });\n  }, 1000<\/span>);\n}, []);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Pushing further<\/h3>\n\n\n\n
Zustand also supports manual, fine-grained subscriptions; bindings for vanilla JavaScript, with no React at all; and integrates well with immutable helpers like Immer. It also has some other, more advanced goodies that we won’t try to cover here. Check out the docs if this post has sparked your interest!<\/p>\n\n\n\n
Concluding Thoughts<\/h2>\n\n\n\n
Zustand is a wonderfully simple, frankly fun library to use to manage state management in React. And as an added bonus, it can also improve your render performance.<\/p>\n","protected":false},"excerpt":{"rendered":"
Zustand is a minimal, but fun and effective state management library which just may improve your render performance.<\/p>\n","protected":false},"author":21,"featured_media":6605,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[3,62,374,373],"class_list":["post-6584","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-javascript","tag-react","tag-state-management","tag-zustand"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2025\/07\/Introducing-Zustand.jpg?fit=1140%2C676&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/6584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=6584"}],"version-history":[{"count":14,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/6584\/revisions"}],"predecessor-version":[{"id":6610,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/6584\/revisions\/6610"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/6605"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=6584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=6584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=6584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}