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

At the end of this part, we will look at a few more different ways to manage the state of an application.

\n

Let's continue with the note application. We will focus on communication with the server. Let's start the application from scratch. The first version is as follows:

\n
const App = () => {\n  const addNote = async (event) => {\n    event.preventDefault()\n    const content = event.target.note.value\n    event.target.reset()\n    console.log(content)\n  }\n\n  const toggleImportance = (note) => {\n    console.log('toggle importance of', note.id)\n  }\n\n  const notes = []\n\n  return (\n    <div>\n      <h2>Notes app</h2>\n      <form onSubmit={addNote}>\n        <input name=\"note\" />\n        <button type=\"submit\">add</button>\n      </form>\n      {notes.map((note) => (\n        <li key={note.id} onClick={() => toggleImportance(note)}>\n          {note.important ? <strong>{note.content}</strong> : note.content}\n          <button onClick={() => toggleImportance(note.id)}>\n            {note.important ? 'make not important' : 'make important'}\n          </button>  \n        </li>\n      ))}\n    </div>\n  )\n}\n\nexport default App
\n

The initial code is on GitHub in this repository, in the branch part6-0.

\n

Managing data on the server with the TanStack Query library

\n

We shall now use the TanStack Query library to store and manage data retrieved from the server.

\n

Install the library with the command

\n
npm install @tanstack/react-query
\n

A few additions to the file main.jsx are needed to pass the library functions to the entire application:

\n
import { createRoot } from 'react-dom/client'\nimport { QueryClient, QueryClientProvider } from '@tanstack/react-query'\nimport App from './App.jsx'\n\nconst queryClient = new QueryClient()\ncreateRoot(document.getElementById('root')).render(\n  <QueryClientProvider client={queryClient}>    <App />\n  </QueryClientProvider>)
\n

Let's use JSON Server as in the previous parts to simulate the backend. JSON Server is preconfigured in the example project, and the project root contains a file db.json that by default has two notes. You can start the server with:

\n
npm run server
\n

We can now retrieve the notes in the App component. The code expands as follows:

\n
import { useQuery } from '@tanstack/react-query'\nconst App = () => {\n  const addNote = async (event) => {\n    event.preventDefault()\n    const content = event.target.note.value\n    event.target.reset()\n    console.log(content)\n  }\n\n  const toggleImportance = (note) => {\n    console.log('toggle importance of', note.id)\n  }\n\n  const result = useQuery({    queryKey: ['notes'],    queryFn: async () => {      const response = await fetch('http://localhost:3001/notes')      if (!response.ok) {        throw new Error('Failed to fetch notes')      }      return await response.json()    }  })   console.log(JSON.parse(JSON.stringify(result)))   if (result.isPending) {    return <div>loading data...</div>  }   const notes = result.data\n  return (\n    // ...\n  )\n}
\n

Fetching data from the server is done, as in the previous chapter, using the Fetch API's fetch function. However, the function call is now wrapped into a query formed by the useQuery function. The call to useQuery takes as its parameter an object with the fields queryKey and queryFn. The value of the queryKey field is an array containing the string notes. It acts as the key for the defined query, i.e. the list of notes.

\n

The return value of the useQuery function is an object that indicates the status of the query. The output to the console illustrates the situation:

\n\"browser\n

That is, the first time the component is rendered, the query is still in pending state, i.e. the associated HTTP request is pending. At this stage, only the following is rendered:

\n
<div>loading data...</div>
\n

However, the HTTP request is completed so quickly that not even Max Verstappen would be able to see the text. When the request is completed, the component is rendered again. The query is in the state success on the second rendering, and the field data of the query object contains the data returned by the request, i.e. the list of notes that is rendered on the screen.

\n

So the application retrieves data from the server and renders it on the screen without using the React hooks useState and useEffect used in chapters 2-5 at all. The data on the server is now entirely under the administration of the TanStack Query library, and the application does not need the state defined with React's useState hook at all!

\n

Let's move the function making the actual HTTP request to its own file src/requests.js

\n
const baseUrl = 'http://localhost:3001/notes'\n\nexport const getNotes = async () => {\n  const response = await fetch(baseUrl)\n  if (!response.ok) {\n    throw new Error('Failed to fetch notes')\n  }\n  return await response.json()\n}
\n

The App component is now slightly simplified:

\n
import { useQuery } from '@tanstack/react-query' \nimport { getNotes } from './requests'\nconst App = () => {\n  // ...\n\n  const result = useQuery({\n    queryKey: ['notes'],\n    queryFn: getNotes  })\n\n  // ...\n}
\n

The current code for the application is in GitHub in the branch part6-1.

\n

Synchronizing data to the server using TanStack Query

\n

Data is already successfully retrieved from the server. Next, we will make sure that the added and modified data is stored on the server. Let's start by adding new notes.

\n

Let's make a function createNote to the file requests.js for saving new notes:

\n
const baseUrl = 'http://localhost:3001/notes'\n\nexport const getNotes = async () => {\n  const response = await fetch(baseUrl)\n  if (!response.ok) {\n    throw new Error('Failed to fetch notes')\n  }\n  return await response.json()\n}\n\nexport const createNote = async (newNote) => {  const options = {    method: 'POST',    headers: { 'Content-Type': 'application/json' },    body: JSON.stringify(newNote)  }   const response = await fetch(baseUrl, options)   if (!response.ok) {    throw new Error('Failed to create note')  }   return await response.json()}
\n

The App component will change as follows

\n
import { useQuery, useMutation } from '@tanstack/react-query'import { getNotes, createNote } from './requests'\nconst App = () => {\n  const newNoteMutation = useMutation({    mutationFn: createNote,  })\n  const addNote = async (event) => {\n    event.preventDefault()\n    const content = event.target.note.value\n    event.target.reset()\n    newNoteMutation.mutate({ content, important: true })  }\n\n  //\n\n}
\n

To create a new note, a mutation is defined using the function useMutation:

\n
const newNoteMutation = useMutation({\n  mutationFn: createNote,\n})
\n

The parameter is the function we added to the file requests.js, which uses Fetch API to send a new note to the server.

\n

The event handler addNote performs the mutation by calling the mutation object's function mutate and passing the new note as an argument:

\n
newNoteMutation.mutate({ content, important: true })
\n

Our solution is good. Except it doesn't work. The new note is saved on the server, but it is not updated on the screen.

\n

In order to render a new note as well, we need to tell TanStack Query that the old result of the query whose key is the string notes should be invalidated.

\n

Fortunately, invalidation is easy, it can be done by defining the appropriate onSuccess callback function to the mutation:

\n
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'import { getNotes, createNote } from './requests'\n\nconst App = () => {\n  const queryClient = useQueryClient()\n  const newNoteMutation = useMutation({\n    mutationFn: createNote,\n    onSuccess: () => {      queryClient.invalidateQueries({ queryKey: ['notes'] })    },  })\n\n  // ...\n}
\n

Now that the mutation has been successfully executed, a function call is made to

\n
queryClient.invalidateQueries({ queryKey: ['notes'] })
\n

This in turn causes TanStack Query to automatically update a query with the key notes, i.e. fetch the notes from the server. As a result, the application renders the up-to-date state on the server, i.e. the added note is also rendered.

\n

Let us also implement the change in the importance of notes. A function for updating notes is added to the file requests.js:

\n
export const updateNote = async (updatedNote) => {\n  const options = {\n    method: 'PUT',\n    headers: { 'Content-Type': 'application/json' },\n    body: JSON.stringify(updatedNote)\n  }\n\n  const response = await fetch(`${baseUrl}/${updatedNote.id}`, options)\n\n  if (!response.ok) {\n    throw new Error('Failed to update note')\n  }\n\n  return await response.json()\n}
\n

Updating the note is also done by mutation. The App component expands as follows:

\n
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'\nimport { getNotes, createNote, updateNote } from './requests'\nconst App = () => {\n  const queryClient = useQueryClient()\n\n  const newNoteMutation = useMutation({\n    mutationFn: createNote,\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['notes'] })\n    }\n  })\n\n  const updateNoteMutation = useMutation({    mutationFn: updateNote,    onSuccess: () => {      queryClient.invalidateQueries({ queryKey: ['notes'] })    }  })\n  const addNote = async (event) => {\n    event.preventDefault()\n    const content = event.target.note.value\n    event.target.reset()\n    newNoteMutation.mutate({ content, important: true })\n  }\n\n  const toggleImportance = (note) => {\n    updateNoteMutation.mutate({...note, important: !note.important })  }\n\n  // ...\n}
\n

So again, the mutation we created invalidates the notes query so that the updated note is rendered correctly. Using mutations is easy, the function mutate receives a note as a parameter, the importance of which has been changed to the negation of the old value.

\n

The current code for the application is on GitHub in the branch part6-2.

\n

Optimizing the performance

\n

The application works well, and the code is relatively simple. The ease of making changes to the list of notes is particularly surprising. For example, when we change the importance of a note, invalidating the query notes is enough for the application data to be updated:

\n
const updateNoteMutation = useMutation({\n  mutationFn: updateNote,\n  onSuccess: () => {\n    queryClient.invalidateQueries({ queryKey: ['notes'] })  }\n})
\n

The consequence of this, of course, is that after the PUT request that causes the note change, the application makes a new GET request to retrieve the query data from the server:

\n\"devtools\n

If the amount of data retrieved by the application is not large, it doesn't really matter. After all, from a browser-side functionality point of view, making an extra HTTP GET request doesn't really matter, but in some situations it might put a strain on the server.

\n

If necessary, it is also possible to optimize performance by manually updating the query state maintained by TanStack Query.

\n

The change for the mutation adding a new note is as follows:

\n
const App = () => {\n  const queryClient = useQueryClient()\n\n  const newNoteMutation = useMutation({\n    mutationFn: createNote,\n    onSuccess: (newNote) => {      const notes = queryClient.getQueryData(['notes'])      queryClient.setQueryData(['notes'], notes.concat(newNote))    }\n  })\n\n  // ...\n}
\n

That is, in the onSuccess callback, the queryClient object first reads the existing notes state of the query and updates it by adding a new note, which is obtained as a parameter of the callback function. The value of the parameter is the value returned by the function createNote, defined in the file requests.js as follows:

\n
export const createNote = async (newNote) => {\n  const options = {\n    method: 'POST',\n    headers: { 'Content-Type': 'application/json' },\n    body: JSON.stringify(newNote)\n  }\n\n  const response = await fetch(baseUrl, options)\n\n  if (!response.ok) {\n    throw new Error('Failed to create note')\n  }\n\n  return await response.json()}
\n

It would be relatively easy to make a similar change to a mutation that changes the importance of the note, but we leave it as an optional exercise.

\n

Finally, note an interesting detail. TanStack Query refetches all notes when we switch to another browser tab and then return to the application's tab. This can be observed in the Network tab of the Developer Console:

\n\"dev\n

What is going on? By reading the documentation, we notice that the default functionality of TanStack Query's queries is that the queries (whose status is stale) are updated when window focus changes. If we want, we can turn off the functionality by creating a query as follows:

\n
const App = () => {\n  // ...\n  const result = useQuery({\n    queryKey: ['notes'],\n    queryFn: getNotes,\n    refetchOnWindowFocus: false  })\n\n  // ...\n}
\n

If you put a console.log statement to the code, you can see from browser console how often TanStack Query causes the application to be re-rendered. The rule of thumb is that rerendering happens at least whenever there is a need for it, i.e. when the state of the query changes. You can read more about it e.g. here.

\n

useNotes custom hook

\n

Our solution is fairly good, but somewhat bothersome is the fact that many TanStack Query implementation details have been placed directly inside the React component. Let's extract these into their own custom hook function:

\n
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'\nimport { getNotes, createNote, updateNote } from '../requests'\n\nexport const useNotes = () => {\n  const queryClient = useQueryClient()\n\n  const result = useQuery({\n    queryKey: ['notes'],\n    queryFn: getNotes,\n    refetchOnWindowFocus: false\n  })\n\n  const newNoteMutation = useMutation({\n    mutationFn: createNote,\n    onSuccess: (newNote) => {\n      const notes = queryClient.getQueryData(['notes'])\n      queryClient.setQueryData(['notes'], notes.concat(newNote))\n    }\n  })\n\n  const updateNoteMutation = useMutation({\n    mutationFn: updateNote,\n    onSuccess: () => {\n      queryClient.invalidateQueries({ queryKey: ['notes'] })\n    }\n  })\n\n  return {\n    notes: result.data,\n    isPending: result.isPending,\n    addNote: (content) => newNoteMutation.mutate({ content, important: true }),\n    toggleImportance: (note) => updateNoteMutation.mutate({ \n      ...note, important: !note.important \n    }),\n  }\n}
\n

The hook function encapsulates all TanStack Query related code: the query for fetching notes and both mutations for creating and updating notes. These implementation details are hidden from the hook's user, as the function returns a simple object containing

\n\n

The App component is simplified considerably:

\n
import { useNotes } from './hooks/useNotes'\n\nconst App = () => {\n  const { notes, isPending, addNote: addNoteToServer, toggleImportance } = useNotes()\n\n  const addNote = async (event) => {\n    event.preventDefault()\n    const content = event.target.note.value\n    event.target.reset()\n    addNoteToServer(content)\n  }\n\n  if (isPending) {\n    return <div>loading data...</div>\n  }\n\n  return (\n    <div>\n      <h2>Notes app</h2>\n      <form onSubmit={addNote}>\n        <input name=\"note\" />\n        <button type=\"submit\">add</button>\n      </form>\n      {notes.map((note) => (\n        <li key={note.id}>\n          {note.important ? <strong>{note.content}</strong> : note.content}\n          <button onClick={() => toggleImportance(note)}>\n            {note.important ? 'make not important' : 'make important'}\n          </button>\n        </li>\n      ))}\n    </div>\n  )\n}
\n

The code for the application is in GitHub in the branch part6-3.

\n

TanStack Query is a versatile library that, based on what we have already seen, simplifies the application. Does TanStack Query make more complex state management solutions such as Zustand unnecessary? No. TanStack Query can partially replace the state of the application in some cases, but as the documentation states

\n\n

So TanStack Query is a library that maintains the server state in the frontend, i.e. acts as a cache for what is stored on the server. TanStack Query simplifies the processing of data on the server, and can in some cases eliminate the need for data on the server to be saved in the frontend state.

\n

Most React applications need not only a way to temporarily store the served data, but also some solution for how the rest of the frontend state (e.g. the state of forms or notifications) is handled.

\n
\n
\n

Exercises 6.16.-6.19.

\n

Now let's make a new version of the anecdote application that uses the TanStack Query library. Take this project as your starting point. The project has a ready-installed JSON Server, the operation of which has been slightly modified (Review the server.js file for more details. Make sure you're connecting to the correct PORT). Start the server with npm run server.

\n

Use the Fetch API to make requests.

\n

Exercise 6.16

\n

Implement retrieving anecdotes from the server using TanStack Query.

\n

The application should work in such a way that if there are problems communicating with the server, only an error page will be displayed:

\n\"browser\n

You can find here info how to detect the possible errors.

\n

You can simulate a problem with the server by e.g. turning off the JSON Server. Please note that in a problem situation, the query is first in the state isPending for a while, because if a request fails, TanStack Query tries the request a few times before it states that the request is not successful. You can optionally specify that no retries are made:

\n
const result = useQuery(\n  {\n    queryKey: ['anecdotes'],\n    queryFn: getAnecdotes,\n    retry: false\n  }\n)
\n

or that the request is retried e.g. only once:

\n
const result = useQuery(\n  {\n    queryKey: ['anecdotes'],\n    queryFn: getAnecdotes,\n    retry: 1\n  }\n)
\n

Exercise 6.17

\n

Implement adding new anecdotes to the server using TanStack Query. The application should render a new anecdote by default. Note that the content of the anecdote must be at least 5 characters long, otherwise the server will reject the POST request. You don't have to worry about error handling now.

\n

Exercise 6.18

\n

Implement voting for anecdotes using again the TanStack Query. The application should automatically render the increased number of votes for the voted anecdote.

\n

Exercise 6.19

\n

Extract the TanStack Query details into a custom hook function.

\n
\n
\n

Context API

\n

Let's return to the good old counter application. The application is defined as follows:

\n
import { useState } from 'react'\nimport Display from './components/Display'\nimport Controls from './components/Controls'\n\nconst App = () => {\n  const [counter, setCounter] = useState(0)\n\n  return (\n    <div>\n      <Display counter={counter} />\n      <Controls counter={counter} setCounter={setCounter} />\n    </div>\n  )\n}
\n

The App component defines the application state and passes it to the Display component, which renders the counter value:

\n
const Display = ({ counter }) => {\n\n  return (\n    <div>{counter}</div>\n  )\n}
\n

and to the Controls component, which renders the buttons:

\n
const Controls = ({ counter, setCounter }) => {\n  const increment = () => setCounter(counter + 1)\n  const decrement = () => setCounter(counter - 1)\n  const zero = () => setCounter(0)\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

The application grows:

\n\n

The role of the App component changes: it still holds the application state, but it no longer renders the components using the counter state directly:

\n
const App = () => {\n  const [counter, setCounter] = useState(0)\n\n  return (\n    <div>\n      <Navbar />\n      <Panel counter={counter} setCounter={setCounter} />\n      <Footer />\n    </div>\n  )\n}
\n

The new Panel component is responsible for rendering the components that display the counter and the buttons:

\n
import Display from './Display'\nimport Controls from './Controls'\n\nconst Panel = ({ counter, setCounter }) => {\n  return (\n    <div>\n      <Display counter={counter} />\n      <Controls counter={counter} setCounter={setCounter} />\n    </div>\n  )\n}
\n

The component hierarchy of the application is as follows:

\n
App (state)\n ├── Panel \n │    ├── Display\n │    └── Controls\n └── Footer
\n

The application state is still in the App component. To allow Display and Controls to access the counter state, the state and its update function must be passed as props through the Panel component, even though Panel itself doesn't need them. This kind of situation arises easily when using state created with the useState hook. This phenomenon is called prop drilling.

\n

React's built-in Context API offers a solution to this problem. A React context is a kind of global state for the application, allowing any component to be given direct access to it.

\n

Let's now create a context in the application that stores the counter state management.

\n

A context is created using React's createContext hook. Let's create the context in a file src/CounterContext.jsx:

\n
import { createContext } from 'react'\n\nconst CounterContext = createContext()\n\nexport default CounterContext
\n

The App component can now provide the context to its child components as follows:

\n
// ...\nimport CounterContext from './components/CounterContext'\n\nconst App = () => {\n  const [counter, setCounter] = useState(0)\n\n  return (\n    <CounterContext.Provider value={{counter, setCounter}}>      <Panel />      <Footer />\n    </CounterContext.Provider>  )\n}
\n

Providing the context is done by wrapping the child components inside the CounterContext.Provider component and setting an appropriate value for the context.

\n

The context value is now an object with the attributes counter and setCounter, i.e. the counter state and the function that updates it.

\n

Note that the Panel component no longer receives any counter-related props, so it simplifies to:

\n
const Panel = () => {\n  return (\n    <div>\n      <Display />\n      <Controls />\n    </div>\n  )\n}
\n

Other components can now access the context using the useContext hook. The Display component changes as follows:

\n
import { useContext } from 'react'import CounterContext from './CounterContext'\nconst Display = () => {  const { counter } = useContext(CounterContext)\n  return <div>{counter}</div>\n}
\n

The Display component no longer needs any props. It gets the counter value by calling the useContext hook with the CounterContext object as its parameter.

\n

Similarly, the Controls component changes to:

\n
import { useContext } from 'react'import CounterContext from './CounterContext'\nconst Controls = () => {\n  const { counter, setCounter } = useContext(CounterContext)\n  const increment = () => setCounter(counter + 1)\n  const decrement = () => setCounter(counter - 1)\n  const zero = () => setCounter(0)\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 components now have access to the content set by the context provider, the counter state and its update function.

\n

The components extract the attributes they need using JavaScript's destructuring syntax:

\n
const { counter } = useContext(CounterContext)
\n

Defining the counter context in its own file

\n

Our application still has the unpleasant feature that the counter state management functionality is defined inside the App component. Let's move all counter-related code to the file CounterContext.jsx:

\n
import { createContext, useState } from 'react'\n\nconst CounterContext = createContext()\n\nexport default CounterContext\n\nexport const CounterContextProvider = (props) => {  const [counter, setCounter] = useState(0)  return (    <CounterContext.Provider value={{ counter, setCounter }}>      {props.children}    </CounterContext.Provider>  )}
\n

The file now exports both the CounterContext object and the CounterContextProvider component, which is essentially a context provider whose value contains the counter and its update function.

\n

Let's use the context provider directly in the file main.jsx:

\n
import { StrictMode } from 'react'\nimport { createRoot } from 'react-dom/client'\n\nimport App from './App'\nimport { CounterContextProvider } from './CounterContext'\ncreateRoot(document.getElementById('root')).render(\n  <CounterContextProvider>    <App />\n  </CounterContextProvider>)
\n

Now the context that defines the counter value and functionality is available to all components in the application.

\n

The App component simplifies to:

\n
import Panel from './components/Panel'\nimport Footer from './components/Footer'\n\nconst App = () => {\n\n  return (\n    <div>\n      <Navbar />\n      <Panel />\n      <Footer />\n  </div>\n  )\n}\n\nexport default App
\n

The context is still used in the same way, and no changes are needed to the other components. For example, Controls remains:

\n
const Controls = () => {\n  const { counter, setCounter } = useContext(CounterContext)\n  const increment = () => setCounter(counter + 1)\n  const decrement = () => setCounter(counter - 1)\n  const zero = () => setCounter(0)\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

The solution is quite good. The entire application state, that is, the counter value, is now isolated in the CounterContext file. Components access exactly the part of the context they need using the useContext hook and JavaScript's destructuring syntax.

\n

Let's make one small improvement and also define the counter update functions increment, decrement, and zero in the context:

\n
import { createContext, useState } from 'react'\n\nconst CounterContext = createContext()\n\nexport default CounterContext\n\nexport const CounterContextProvider = (props) => {\n  const [counter, setCounter] = useState(0)\n\n  const increment = () => setCounter(counter + 1)  const decrement = () => setCounter(counter - 1)  const zero = () => setCounter(0)\n  return (\n    <CounterContext.Provider value={{ counter, increment, decrement, zero }}>      {props.children}\n    </CounterContext.Provider>\n  )\n}
\n

Now we can use the functions obtained from the context directly as button event handlers:

\n
import { useContext } from 'react'\nimport CounterContext from '../CounterContext' \n\nconst Controls = () => {\n  const { increment, decrement, zero } = useContext(CounterContext)\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

There is still room for one more improvement. If we look at how the counter context is used, we notice that the same boilerplate appears in both components that consume it:

\n
import { useContext } from 'react'\nimport CounterContext from '../CounterContext' \n\nconst Display = () => {\n  const { counter } = useContext(CounterContext)\n  // ...\n}
\n
import { useContext } from 'react'\nimport CounterContext from '../CounterContext' \n\nconst Controls = () => {\n  const { increment, decrement, zero } = useContext(CounterContext)  // ...\n}
\n

We can take the solution one step further by creating a custom hook that returns the context directly. Let's add it to the file hooks/useCounter.js:

\n
import { useContext } from 'react'\nimport CounterContext from '../CounterContext'\n\nconst useCounter = () => useContext(CounterContext)\n\nexport default useCounter
\n

Using the context is now one step simpler:

\n
import { useCounter } from '../hooks/useCounter'\n\nconst Display = () => {\n  const { counter } = useCounter()\n  // ...\n}\n\nimport { useCounter } from '../hooks/useCounter'\n\nconst Controls = () => {\n  const { increment, decrement, zero } = useCounter()\n  // ...\n}
\n

We are satisfied with the solution. It isolates all state management entirely within the context. The components that use the state have no knowledge of how the state is implemented — thanks to the custom hook, they are not even really aware that the solution is based on the Context API.

\n

The application code is in the GitHub repository https://github.com/fullstack-hy2020/context-counter.

\n
\n
\n

Exercises 6.20.-6.22.

\n

Exercise 6.20.

\n

The application has a Notification component for displaying notifications to the user.

\n

Implement the application's notification state management using the Context API. The notification should tell the user when a new anecdote is created or an anecdote is voted on:

\n\"browser\n

The notification is displayed for five seconds.

\n

Exercise 6.21.

\n

As stated in exercise 6.17, the server requires that the content of the anecdote to be added is at least 5 characters long. Now implement error handling for the insertion. In practice, it is sufficient to display a notification to the user in case of a failed POST request:

\n\"browser\n

The error condition should be handled in the callback function registered for it, see here how to register a function.

\n

Exercise 6.22.

\n

If you haven't done so already, move the notification-related context into its own file NotificationContext.jsx, in the same way as the counter application's context was moved to CounterContext.jsx in the material. Also create a custom hook useNotify that encapsulates the notification logic. Simplify the components that use the notification so that they call the hook directly instead of calling useContext separately.

\n

This was the last exercise for this part of the course and it's time to push your code to GitHub and mark all of your completed exercises to the exercise submission system.

\n
\n
\n

Which state management solution to choose?

\n

In chapters 1-5, all state management in the application was handled using React's useState hook. Asynchronous calls to the backend required the use of the useEffect hook in some situations. In principle, nothing else is needed.

\n

A subtle issue with solutions based on state created with the useState hook is that if some part of the application state is needed by multiple components, the state and the functions for manipulating it must be passed via props to all components that handle that state. Sometimes props need to be passed through multiple components, and the components along the way may not even be interested in the state in any way. This somewhat unpleasant phenomenon is called prop drilling.

\n

Over the years, several alternative solutions have been developed for state management in React applications, which can be used to ease problematic situations such as prop drilling. However, no solution has been \"final\" — all have their own pros and cons, and new solutions are being developed all the time.

\n

The situation may confuse a beginner and even an experienced web developer. Which solution should be used?

\n

For a simple application, useState is certainly a good starting point. If the application communicates with a server, the communication can be handled in the same way as in chapters 1-5, using the application's own state. Recently, however, it has become more common to move the communication and associated state management at least partially under the control of TanStack Query (or some other similar library). If you are concerned about useState and the prop drilling it entails, using context may be a good option. There are also situations where it may make sense to handle some of the state with useState and some with contexts.

\n

For a long time, the most popular and comprehensive state management solution has been Redux, which is a way to implement the so-called Flux architecture. Redux is, however, known for its complexity and abundance of boilerplate code, which has been the motivation for newer state management solutions. In this course material, Redux has been replaced by the Zustand library, which provides equivalent functionality with a considerably simpler API. Zustand has become a popular choice especially when you need more than what useState offers, but the full Redux machinery feels excessive. Some of the criticism directed at Redux's rigidity has become outdated thanks to the Redux Toolkit, and Redux is still widely used, especially in larger projects.

\n

Neither Zustand nor Redux has to be used throughout the entire application. It may make sense, for example, to manage form state outside of them, especially in situations where the form state does not affect the rest of the application. Using Zustand or Redux together with TanStack Query in the same application is also perfectly possible.

\n

The question of which state management solution to use is not at all straightforward. It is impossible to give a single correct answer, and it is also likely that the chosen solution may turn out to be suboptimal as the application grows, requiring the approach to be changed even if the application has already been put into production.

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