{"componentChunkName":"component---src-templates-content-template-js","path":"/en/part6/flux_architecture_and_zustand","result":{"data":{"markdownRemark":{"html":"
\n

We have followed React's recommended practice for managing application state by defining the state needed by multiple components and the functions that handle it in the top-level components of the component hierarchy. Most of the state and the functions handling it have typically been defined directly in the root component and passed via props to the components that need them. This works up to a point, but as the application grows, state management becomes challenging.

\n

Flux architecture

\n

Facebook developed the Flux architecture in the early days of React's history to ease state management problems. In Flux, the management of application state is separated entirely into external stores outside of React components. The state in the store is not changed directly but through specific actions that are created to that purpose.

\n

When an action changes the store's state, the views are re-rendered:

\n\"Action Dispatcher -> Store -> View\" srcset=\"/static/165b40470776ac449f8b9604d4828004/772e8/flux1.png 200w,\n/static/165b40470776ac449f8b9604d4828004/e17e5/flux1.png 400w,\n/static/165b40470776ac449f8b9604d4828004/5a190/flux1.png 800w,\n/static/165b40470776ac449f8b9604d4828004/c1b63/flux1.png 1200w,\n/static/165b40470776ac449f8b9604d4828004/29007/flux1.png 1600w,\n/static/165b40470776ac449f8b9604d4828004/090a8/flux1.png 2504w\" sizes=\"(max-width: 800px) 100vw, 800px\">\n

If the use of the application (e.g., pressing a button) causes a need to change the state, the change is made through an action. This in turn causes the view to be re-rendered:

\n\"Action Dispatcher -> Store -> View -> Action -> Dispatcher -> View\" srcset=\"/static/7bf90479b6757c7af3b9a9f0e7f19a64/772e8/flux2.png 200w,\n/static/7bf90479b6757c7af3b9a9f0e7f19a64/e17e5/flux2.png 400w,\n/static/7bf90479b6757c7af3b9a9f0e7f19a64/5a190/flux2.png 800w,\n/static/7bf90479b6757c7af3b9a9f0e7f19a64/c1b63/flux2.png 1200w,\n/static/7bf90479b6757c7af3b9a9f0e7f19a64/29007/flux2.png 1600w,\n/static/7bf90479b6757c7af3b9a9f0e7f19a64/a5262/flux2.png 2388w\" sizes=\"(max-width: 800px) 100vw, 800px\">\n

Flux thus provides a standard way for how and where the application state is kept and for making changes to it.

\n

Redux

\n

Redux, which follows the Flux architecture, was the dominant state management solution for React applications for nearly a decade. On this course, Redux was also used until spring 2026. Redux has always been plagued by complexity and a large amount of boilerplate code. The situation improved significantly with the introduction of Redux Toolkit, but despite this, the community continued to develop alternative state management solutions, such as MobX, Recoil and Jotai. Their popularity has varied.

\n

The most interesting, and without a doubt the most popular of the new arrivals is Zustand, and it is also our choice for a state management solution. Zustand appears to have already caught up with Redux in popularity:

\n\n

Zustand

\n

Let's get familiar with Zustand by once again implementing a counter application:

\n\"Rendered\n

Create a new Vite application and install Zustand:

\n
npm install zustand
\n

The first version, where only the counter increment works, is as follows:

\n
import { create } from 'zustand'\n\nconst useCounterStore = create(set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),\n}))\n\nconst App = () => {\n  const counter = useCounterStore(state => state.counter)\n  const increment = useCounterStore(state => state.increment)\n\n  return (\n    <div>\n      <div>{counter}</div>\n      <div>\n        <button onClick={increment}>plus</button>\n        <button>minus</button>\n        <button>zero</button>\n      </div>\n      \n    </div>\n  )\n}
\n

The application starts by creating the store, i.e., the global state, using Zustand's create function:

\n
import { create } from 'zustand'\n\nconst useCounterStore = create(set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),\n}))
\n

The function receives as a parameter a function that returns the state to be defined for the application. The parameter is thus the following:

\n
set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),\n})
\n

The state thus has counter defined with a value of zero, and increment which is a function.

\n

The application's components can access the values and functions defined in the state through the useCounterStore function defined using Zustand's create. The App component uses selectors to retrieve the counter value and the increment function from the state:

\n
const App = () => {\n  // using selector to pick right part of the store state  const counter = useCounterStore(state => state.counter)  const increment = useCounterStore(state => state.increment)\n  return (\n    <div>\n      <div>{counter}</div>      <div>\n        <button onClick={increment}>plus</button>        <button>minus</button>\n        <button>zero</button>\n      </div>\n      \n    </div>\n  )\n}
\n

The code stores counter value of the store into a variable as follows:

\n
const counter = useCounterStore(state => state.counter)
\n

A selector function state => state.counter is used, which determines what is returned from the store's contents. In the same way, the function stored in the store is retrieved into the variable increment.

\n

The state function increment, which was defined as follows, is given as the click handler for the \"plus\" button:

\n
const useCounterStore = create(set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),}))
\n

Let's look at the function definition separately:

\n
() => set(state => ({ counter: state.counter + 1 }))
\n

This is a function that calls the set function giving another function as a parameter. This function passed as a parameter defines how the state changes:

\n
state => ({ counter: state.counter + 1 })
\n

which is shorthand for:

\n
state => {\n  return { counter: state.counter + 1 }\n}
\n

The function returns a new state, which it computes based on the old state that it can access using the parameter state. So if the old state is, for example:

\n
{\n  counter: 1,\n  increment: // function definition\n}
\n

the new state becomes:

\n
{\n  counter: 2,\n  increment: // function definition\n}
\n

The state always also contains the state-changing function increment.

\n

The state transition function

\n
state => ({ counter: state.counter + 1 })
\n

only affects the counter value in the state.

\n

Nothing would prevent changing the function in the state within the state transition function; for example, if we defined it as follows:

\n
state => {\n  return {\n    counter: state.counter + 1 ,\n    increment: console.log('increment broken')\n  }\n}
\n

the increment button would only work the first time; after that, pressing the button would only print to the console.

\n

When the new state is set as:

\n
state => ({ counter: state.counter + 1 })
\n

only the value of the counter key in the state is updated; the new state is obtained by merging the old state with the value returned by the state-changing function. This is why the following state transition function:

\n
state => ({})
\n

does not affect the state at all.

\n

Let's complete the application for the remaining buttons as well:

\n
const useCounterStore = create(set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),\n  decrement: () => set(state => ({ counter: state.counter - 1 })),\n  zero: () => set(() => ({ counter: 0 })),  \n}))\n\nconst App = () => {\n  const counter = useCounterStore(state => state.counter)\n  const increment = useCounterStore(state => state.increment)\n  const decrement = useCounterStore(state => state.decrement)\n  const zero = useCounterStore(state => state.zero)\n\n  return (\n    <div>\n      <div>{counter}</div>\n      <div>\n        <button onClick={increment}>plus</button>\n        <button onClick={decrement}>minus</button>\n        <button onClick={zero}>zero</button>\n      </div>\n      \n    </div>\n  )\n}
\n
\n

Where do set and state come from?

\n

Where does set come from? It is a helper function provided by Zustand's create function, used to update the state. create calls the parameter function it receives and automatically passes set to it. You don't need to call or import it yourself; Zustand takes care of that.

\n

Where does state come from? When a function is given as a parameter to set (instead of a new state object directly), Zustand calls that function with the store's current state as its argument. This way, state-updating functions can access the old state to compute the new one.

\n
\n

Using the state from different components

\n

Let's refactor the application so that the store definition is moved to its own file store.js, and the view is split into multiple components, each defined in their own files.

\n

The contents of store.js are straightforward:

\n
export const useCounterStore = create(set => ({\n  counter: 0,\n  increment: () => set(state => ({ counter: state.counter + 1 })),\n  decrement: () => set(state => ({ counter: state.counter - 1 })),\n  zero: () => set(() => ({ counter: 0 })),  \n}))
\n

The App component is simplified as follows:

\n
import Display from './Display'\nimport Controls from './Controls'\n\nconst App = () => {\n  return (\n    <div>\n      <Display />\n      <Controls />\n    </div>\n  )\n}\n\nexport default App
\n

What is noteworthy here is that the App component no longer passes state to its child components. In fact, the component does not touch the state in any way, the store definition has been fully separated outside the component.

\n

The component that renders the counter value is simple:

\n
import { useCounterStore } from './store'\n\nconst Display = () => {\n  const counter = useCounterStore(state => state.counter)\n\n  return (\n    <div>{counter}</div>\n  )\n}\n\nexport default Display
\n

The component accesses the counter value via the useCounterStore function that defines the store. This is convenient in many ways, for example, there is no need to pass the state to the component through props.

\n

The component that defines the buttons looks like this:

\n
import { useCounterStore } from './store'\n\nconst Controls = () => {\n  const increment = useCounterStore(state => state.increment)\n  const decrement = useCounterStore(state => state.decrement)\n  const zero = useCounterStore(state => state.zero)\n\n  return (\n    <div>\n      <button onClick={increment}>plus</button>\n      <button onClick={decrement}>minus</button>\n      <button onClick={zero}>zero</button>\n    </div>\n  )\n}\n\nexport default Controls
\n

The useCounterStore function takes a selector function as its parameter, which determines which part of the state to use. For example:

\n
  const increment = useCounterStore(state => state.increment)
\n

Here the selector function state => state.increment picks the value of the increment key from the state — the function that increments the counter — and stores it in the variable increment.

\n

We could also access the entire state as follows:

\n
  const state = useCounterStore()\n  // does the same as useCounterStore(state => state), i.e., selects the entire state
\n

We could then refer to the counter value and the functions using dot notation, i.e., state.counter and state.increment.

\n

A natural question arises: would it be possible to use multiple parts of the state via destructuring:

\n
import { useCounterStore } from './store'\n\nconst Controls = () => {\n  const { increment, decrement, zero } = useCounterStore()\n  return (\n    <div>\n      <button onClick={increment}>plus</button>\n      <button onClick={decrement}>minus</button>\n      <button onClick={zero}>zero</button>\n    </div>\n  )\n}\n\nexport default Controls
\n

The solution works, but it has a significant drawback. Destructuring causes the Controls component to be re-rendered every time the counter value changes, even though the component only displays the buttons and not the value itself.

\n

The best practice in Zustand is therefore to select from the state exactly only those parts that are needed in the given component. A component re-renders only when the part of the state it has selected changes. When instead writing:

\n
  const { increment, decrement, zero } = useCounterStore()
\n

the component no longer reacts to changes in the counter value, because it has not selected it from the state.

\n

Reorganizing the state

\n

However, we can achieve quite a neat solution by reorganizing the state as follows:

\n
export const useCounterStore = create(set => ({\n  counter: 0,\n  actions: {\n    increment: () => set(state => ({ counter: state.counter + 1 })),\n    decrement: () => set(state => ({ counter: state.counter - 1 })),\n    zero: () => set(() => ({ counter: 0 })),\n  }  \n}))
\n

The state-changing functions are now grouped under their own key actions, and they can be selected as a whole and destructured:

\n
const Controls = () => {\n  \n  const { increment, decrement, zero } = useCounterStore(state => state.actions)\n\n  return (\n    <div>\n      <button onClick={increment}>plus</button>\n      <button onClick={decrement}>minus</button>\n      <button onClick={zero}>zero</button>\n    </div>\n  )\n}
\n

Now no re-rendering occurs, since only the functions have been selected from the state, and they remain the same for the entire lifetime of the store.

\n

According to some best practices, it is not advisable to export the function defining the entire state for use throughout the application. Instead, smaller views that expose only the necessary parts of the state should be created from it. Let's modify store.js as follows:

\n
import { create } from 'zustand'\n\nconst useCounterStore = create(set => ({\n  counter: 0,\n  actions: {\n    increment: () => set(state => ({ counter: state.counter + 1 })),\n    decrement: () => set(state => ({ counter: state.counter - 1 })),\n    zero: () => set(() => ({ counter: 0 })),\n  }  \n}))\n\n// the hook functions that are used elsewhere in app\nexport const useCounter = () => useCounterStore(state => state.counter)\nexport const useCounterControls = () => useCounterStore(state => state.actions)
\n

Now, outside the module defining the state, the functions useCounter — which returns the counter value when called — and useCounterControls — which returns the functions that modify the counter value — are available. The usage changes slightly:

\n
import { useCounter } from './store'\nconst Display = () => {\n  const counter = useCounter()\n  return (\n    <div>{counter}</div>\n  )\n}
\n
import { useCounterControls } from './store'\nconst Controls = () => {\n  const { increment, decrement, zero } = useCounterControls()\n  return (\n    <div>\n      <button onClick={increment}>plus</button>\n      <button onClick={decrement}>minus</button>\n      <button onClick={zero}>zero</button>\n    </div>\n  )\n}
\n

When using the state this way, there is no longer a need to use selector functions, as their use is hidden inside the definition of the new helper functions.

\n

The more observant have noticed that the Zustand-related functions are named starting with the word use. The reason for this is that the function returned by Zustand's create function — in our example useCounterStore — is a React custom hook function. Our own helper functions useCounter and useCounterControls are also essentially custom hooks, because they hide the use of the custom hook useCounterStore inside them.

\n

Custom hooks come with a set of rules, for example, their names are expected to always start with use. The rules of hooks covered in Part 1 also apply to custom hooks!

\n
\n
\n

Exercise 6.1.

\n

Let's make a new version of the Unicafe exercise from Part 1. We'll handle the application's state management using Zustand.

\n

You can use the project at https://github.com/fullstack-hy2020/unicafe-zustand as the base for your application.

\n

Start by removing the Git configuration of the cloned application and installing the dependencies:

\n
cd unicafe-zustand   // go to the cloned repository directory\nrm -rf .git\nnpm install
\n

6.1: Unicafe revisited

\n

Then implement the full original functionality of the application.

\n

Your application's appearance and functionality should be the same as in Part 1:

\n\n
\n
\n

Zustand notes

\n

Our goal is to make a Zustand-based version of the good old notes application.

\n

The first version of the application is the following. The App component:

\n
import { useNotes } from './store'\n\nconst App = () => {\n  const notes = useNotes()\n\n  return (\n    <div>\n      <ul>\n        {notes.map(note => (\n          <li key={note.id}>\n            {note.important ? <strong>{note.content}</strong> : note.content}\n          </li>\n        ))}\n      </ul>\n    </div>\n  )\n}\nexport default App
\n

Store is initially defined as follows:

\n
import { create } from 'zustand'\n\nconst useNoteStore = create(set => ({\n  notes: [\n    {\n      id: 1,\n      content: 'Zustand is less complex than Redux',\n      important: true,\n    },\n  ],\n}))\n\nexport const useNotes = () => useNoteStore(state => state.notes)
\n

For now, the application does not have the functionality to add new notes, and the strore does not yet support it. The state has been initialized with one note already added so that we can verify the application can successfully render the state.

\n

Pure functions and immutable objects

\n

The first attempt at an action that adds a note is the following:

\n
note => set(\n          state => {\n            state.notes.push(note)\n            return state\n          }\n        )
\n

The function receives a note as a parameter and returns a state where a new note has been added to the old state state.

\n

Our attempt is, however, against the rules. Zustand's documentation states Like with React's useState, we need to update state immutably. As we know, state.notes.push mutates the state object, so the solution must be changed.

\n

The proper way is to use, for example, the Array.concat function, which does not modify the existing state but creates a new copy of it with the new note added:

\n
note => set(\n          state => {\n            return { notes: state.notes.concat(note) }\n          }\n        )
\n

The store definition now looks as follows:

\n
import { create } from 'zustand'\n\nconst useNoteStore = create(set => ({\n  notes: [],\n  actions: {\n    add: note => set(\n      state => ({ notes: state.notes.concat(note) })\n    )\n  }\n}))\n\nexport const useNotes = () => useNoteStore(state => state.notes)\nexport const useNoteActions = () => useNoteStore(state => state.actions)
\n
\n

Array spread syntax

\n

Another commonly seen way to do the same thing is to use the array spread syntax:

\n
state => ({ notes: [...state.notes, note] })
\n

Here, an array is formed by spreading each element of the state.notes array using spread syntax, and then appending the new note at the end. It is a matter of preference whether to use spread or the concat function.

\n
\n

Technically speaking, state created with Zustand is immutable, and the action functions that modify the state must be pure functions.

\n

Pure functions are those that produce no side effects and always return the same result when called with the same parameters.

\n

Uncontrolled form

\n

Let's add the ability to create new notes to the application:

\n
import { useNotes, useNoteActions } from './store'\n\nconst App = () => {\n  const notes = useNotes()\n  const { add } = useNoteActions()\n  const generateId = () => Number((Math.random() * 1000000).toFixed(0))\n  const addNote = (e) => {    e.preventDefault()    const content = e.target.note.value    add({ id: generateId(), content, important: false })    e.target.reset()  }\n  return (\n    <div>\n      <form onSubmit={addNote}>        <input name=\"note\" />        <button type=\"submit\">add</button>      </form>      <ul>\n        {notes.map(note => (\n          <li key={note.id}>\n            {note.important ? <strong>{note.content}</strong> : note.content}\n          </li>\n        ))}\n      </ul>\n    </div>\n  )\n}
\n

The implementation is fairly straightforward. What is noteworthy about adding a new note is that, unlike previous React-implemented forms, we have not bound the form field's value to the state of the App component. React calls such forms uncontrolled.

\n
\n

Uncontrolled forms have certain limitations. They do not allow, for example, providing validation messages on the fly, disabling the submit button based on content, and so on. However, they are suitable for our use case this time.\nYou can read more about the topic here if you wish.

\n
\n

The form is very simple:

\n
<form onSubmit={addNote}>\n  <input name=\"note\" />\n  <button type=\"submit\">add</button>\n</form>
\n

What is noteworthy about the form is that the input field has a name. This allows the handler function to access the field's value.

\n

The addition handler is also straightforward:

\n
  const addNote = (e) => {\n    e.preventDefault()\n    const content = e.target.note.value\n    add({ id: generateId(), content, important: false })\n    e.target.reset()\n  }
\n

The content is retrieved from the form's text field using e.target.note.value into a variable, which is used as a parameter in the call to the note-adding function add.

\n

The last line, e.target.reset(), clears the form.

\n

The current code of the application is available in its entirety on GitHub, in the branch part6-1.

\n

More components and functionality

\n

Let's split the application into more components. We'll separate the creation of a new note, the list of notes, and the display of a single note into their own components.

\n

The App component after the change is simple:

\n
const App = () => (\n  <div>\n    <NoteForm />\n    <NoteList />\n  </div>\n)
\n

Note creation, i.e., NoteForm, doesn't contain anything dramatic, so the code is not shown here.

\n

The component responsible for listing notes, NoteList, looks like the following:

\n
import { useNotes } from './store'\nimport Note from './Note'\n\nconst NoteList = () => {\n  const notes = useNotes()\n\n  return (\n    <ul>\n      {notes.map(note => (\n        <Note key={note.id} note={note} />\n      ))}\n    </ul>\n  )\n}
\n

The component fetches the list of notes from the store and creates a corresponding Note component for each, passing the note's data as props:

\n
const Note = ({ note }) => (\n  <li>\n    {note.important ? <strong>{note.content}</strong> : note.content}\n  </li>\n)
\n

Let's also add the ability to toggle the importance of a note. The component after the change is the following:

\n
import { useNoteActions } from './store'\n\nconst Note = ({ note }) => {\n  const { toggleImportance } = useNoteActions()\n  return (\n    <li>\n      {note.important ? <strong>{note.content}</strong> : note.content}\n      <button onClick={() => toggleImportance(note.id)}>        {note.important ? 'make not important' : 'make important'}      </button>    </li>\n  )\n}
\n

The component destructures the importance-toggling function from the return value of useNoteActions, and calls it when the toggle button is clicked.

\n

The implementation of the importance-toggling function looks like the following:

\n
import { create } from 'zustand'\n\nconst useNoteStore = create(set => ({\n  notes: [],\n  actions: {\n    add: note => set(\n      state => ({ notes: state.notes.concat(note) })\n    ),\n    toggleImportance: id => set(      state => ({        notes: state.notes.map(note =>          note.id === id ? { ...note, important: !note.important } : note        )      })    )  }\n}))
\n

The function receives the id of the note to be modified as a parameter. The new state is formed from the old state using the map function such that all old notes are included, except for the note to be modified, for which a version is created where its importance is toggled:

\n
{ ...note, important: !note.important }
\n

The current code of the application is available in its entirety on GitHub, in the branch part6-2.

\n
\n
\n

Exercises 6.2.-6.6.

\n

Let's implement a new version of the anecdote voting application from Part 1. Use the project at https://github.com/fullstack-hy2020/zustand-anecdotes as the base for your solution.

\n

If you clone the project inside an existing Git repository, remove the Git configuration of the cloned application:

\n
cd zustand-anecdotes  // go to the cloned repository directory\nrm -rf .git
\n

The application starts normally, but you need to install the dependencies first:

\n
npm install\nnpm run dev
\n

When completing the following exercises, the application should look like this:

\n\"The\n

6.2: anecdotes, step1

\n

Implement the ability to vote for anecdotes. The number of votes must be stored in the Zustand store.

\n

6.3: anecdotes, step2

\n

Add the ability to add new anecdotes to the application.

\n

You can keep the addition form uncontrolled as in the earlier example.

\n

6.4: anecdotes, step3

\n

Separate the creation of a new anecdote into its own component called AnecdoteForm and separate the display of the anecdote list into its own component called AnecdoteList.

\n

After this exercise, the App component should look as follows:

\n
import AnecdoteForm from './components/AnecdoteForm'\nimport AnecdoteList from './components/AnecdoteList'\n\nconst App = () => {\n  return (\n    <div>\n      <h2>Anecdotes</h2>\n      <AnecdoteList />\n      <AnecdoteForm />\n    </div>\n  )\n}\n\nexport default App
\n

6.5: anecdotes, step4

\n

Ensure that the anecdotes are kept in descending order by number of votes.

\n

NOTE In this exercise it is advisable to use the Array.toSorted function, which does not sort the original array but creates a sorted copy of it. This is because the Zustand state must not be mutated!

\n
","frontmatter":{"mainImage":{"publicURL":"/static/a3b7bc3fafcb5b47227616e1343970e5/part-6.svg"},"part":6,"letter":"a","lang":"en"}}},"pageContext":{"part":6,"letter":"a","lang":"en"}},"staticQueryHashes":["3128451518"]}