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

Al final de esta parte, analizaremos algunas formas diferentes de administrar el estado de una aplicación.

\n

Continuemos con la aplicación de notas. Nos centraremos en la comunicación con el servidor. Comencemos la aplicación desde cero. La primera versión es la siguiente:

\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

El código inicial está en GitHub en este repositorio, en la rama part6-0.

\n

Gestión de datos del servidor con la librería TanStack Query

\n

Ahora utilizaremos la librería TanStack Query para almacenar y gestionar los datos obtenidos del servidor.

\n

Instala la librería con el comando

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

Se necesitan agregar algunas cosas en el archivo main.jsx para pasar las funciones de la librería a toda la aplicación:

\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

Usemos JSON Server como en las partes anteriores para simular el backend. JSON Server está preconfigurado en el proyecto de ejemplo, y la raíz del proyecto contiene un archivo db.json que por defecto tiene dos notas. Puedes iniciar el servidor con:

\n
npm run server
\n

Ahora podemos recuperar las notas en el componente App. El código se expande de la siguiente manera:

\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

La obtención de datos del servidor se realiza, como en el capítulo anterior, usando el método fetch de la Fetch API. Sin embargo, la llamada al método ahora está envuelta en una query (consulta) formada con la función useQuery. La llamada a useQuery toma como parámetro un objeto con los campos queryKey y queryFn. El valor del campo queryKey es un array que contiene el string notes. Actúa como la clave para la query definida, es decir, la lista de notas.

\n

El valor devuelto por la función useQuery es un objeto que indica el estado de la query. La salida a la consola ilustra la situación:

\n\"consola\n

Es decir, la primera vez que se renderiza el componente, la query todavía está en estado loading, es decir, la solicitud HTTP asociada está pendiente. En esta etapa, solo se procesa lo siguiente:

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

Sin embargo, la solicitud HTTP se completa tan rápido que ni siquiera Max Verstappen podría ver el texto. Cuando se completa la solicitud, el componente se renderiza de nuevo. La query está en el estado success en la segunda renderización, y el campo data del objeto de la query contiene los datos devueltos por la solicitud, es decir, la lista de notas que se muestran en la pantalla.

\n

Entonces, la aplicación recupera datos del servidor y los renderiza en la pantalla sin usar los Hooks de React useState y useEffect utilizados en los capítulos 2-5. Los datos en el servidor ahora están completamente bajo la administración de la librería TanStack Query, ¡y la aplicación no necesita el estado definido con el Hook de React useState en absoluto!

\n

Movamos la función que realiza la solicitud HTTP a su propio archivo 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

El componente App ahora se ha simplificado un poco:

\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

El código actual de la aplicación está en GitHub en la rama part6-1.

\n

Sincronización de datos con el servidor mediante TanStack Query

\n

Los datos ya se han recuperado correctamente del servidor. A continuación, nos aseguraremos de que los datos agregados y modificados se almacenen en el servidor. Comencemos agregando nuevas notas.

\n

Hagamos una función createNote en el archivo requests.js para guardar nuevas notas:

\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

El componente App cambiará de la siguiente manera

\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

Para crear una nueva nota, se define una mutación usando la función useMutation:

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

El parámetro es la función que agregamos al archivo requests.js, que usa la Fetch API para enviar una nueva nota al servidor.

\n

El controlador de eventos addNote realiza la mutación llamando a la función mutate del objeto de mutación y pasando la nueva nota como parámetro:

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

Nuestra solución es buena. Excepto que no funciona. La nueva nota se guarda en el servidor, pero no se actualiza en la pantalla.

\n

Para renderizar una nueva nota también, debemos decirle a TanStack Query que el resultado antiguo de la query cuya clave es el string notes debe ser invalidado.

\n

Afortunadamente, la invalidación es fácil, se puede hacer definiendo la función de callback onSuccess apropiada para la mutación:

\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

Ahora que la mutación se ha ejecutado con éxito, se realiza una llamada a la función

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

Esto a su vez hace que TanStack Query actualice automáticamente una query con la clave notes, es decir, obtenga las notas del servidor. Como resultado, la aplicación renderiza el estado actualizado en el servidor, es decir, la nota agregada también se renderiza.

\n

Implementemos también el cambio en la importancia de las notas. Se agrega una función para actualizar notas al archivo 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

Actualizar la nota también se hace mediante una mutación. El componente App se expande de la siguiente manera:

\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

De nuevo, se creó una mutación que invalidó la query notes para que la nota actualizada se renderice correctamente. Usar mutaciones es fácil, el método mutate recibe una nota como parámetro, cuya importancia se cambia a la negación del valor antiguo.

\n

El código actual de la aplicación está en GitHub en la rama part6-2.

\n

Optimizando el rendimiento

\n

La aplicación funciona bien y el código es relativamente simple. La facilidad para realizar cambios en la lista de notas es particularmente sorprendente. Por ejemplo, cuando cambiamos la importancia de una nota, invalidar la query notes es suficiente para que los datos de la aplicación se actualicen:

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

La consecuencia de esto, por supuesto, es que después de la solicitud PUT que causa el cambio de nota, la aplicación realiza una nueva solicitud GET para recuperar los datos de la query desde el servidor:

\n\"pestaña\n

Si la cantidad de datos obtenidos por la aplicación no es grande, realmente no importa. Después de todo, desde el punto de vista de la funcionalidad del lado del navegador, hacer una solicitud HTTP GET adicional realmente no importa, pero en algunas situaciones podría generar una carga en el servidor.

\n

Si fuera necesario, es posible también optimizar el rendimiento manualmente, actualizando el estado de la query mantenido por TanStack Query.

\n

El cambio para la mutación que agrega una nueva nota es el siguiente:

\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

Es decir, en el callback de onSuccess, el objeto queryClient primero lee el estado existente de notes de la query y lo actualiza agregando una nueva nota, que se obtiene como parámetro de la función de callback. El valor del parámetro es el valor devuelto por la función createNote, definida en el archivo requests.js de la siguiente manera:

\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

Sería relativamente fácil hacer un cambio similar a una mutación que cambia la importancia de la nota, pero lo dejamos como un ejercicio opcional.

\n

Finalmente, nota un detalle interesante. TanStack Query vuelve a obtener todas las notas cuando cambiamos a otra pestaña del navegador y luego regresamos a la pestaña de la aplicación. Esto se puede observar en la pestaña de Red de la Consola de Desarrollador:

\n\"aplicación\n

¿Qué está pasando? Al leer la documentación, nos damos cuenta de que la funcionalidad predeterminada de las queries de TanStack Query es que las queries (cuyo estado es stale) se actualicen cuando cambia el window focus. Si queremos, podemos desactivar la funcionalidad creando una consulta de la siguiente manera:

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

Si colocas un console.log en el código, podrás ver desde la consola del navegador cuántas veces TanStack Query hace que la aplicación se vuelva a renderizar. La regla general es que el renderizado ocurre al menos cada vez que es necesario, es decir, cuando cambia el estado de la query. Puedes leer más al respecto por ejemplo aquí.

\n

Hook personalizado useNotes

\n

Nuestra solución es bastante buena, pero resulta algo incómodo que muchos detalles de implementación de TanStack Query estén directamente en el componente de React. Extraigámoslos a un hook personalizado:

\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

El hook encapsula todo el código relacionado con TanStack Query: la query que obtiene las notas y las dos mutaciones que las crean y actualizan. Estos detalles quedan ocultos para quien utiliza el hook, ya que la función devuelve un objeto sencillo con:

\n\n

El componente App se simplifica considerablemente:

\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

El código de la aplicación está en GitHub en la rama part6-3.

\n

TanStack Query es una librería versátil que, basándonos en lo que ya hemos visto, simplifica la aplicación. ¿Hace TanStack Query que soluciones de gestión de estado más complejas como Redux sean innecesarias? No. TanStack Query puede reemplazar parcialmente el estado de la aplicación en algunos casos, pero como lo indica la documentación:

\n\n

Entonces, TanStack Query es una librería que mantiene el estado del servidor en el frontend, es decir, actúa como una caché para lo que se almacena en el servidor. TanStack Query simplifica el procesamiento de datos en el servidor y, en algunos casos, puede eliminar la necesidad de que los datos en el servidor se guarden en el estado del frontend.

\n

La mayoría de las aplicaciones de React no necesitan solo una forma de almacenar temporalmente los datos servidos, sino también alguna solución para cómo se maneja el resto del estado del frontend (por ejemplo, el estado de los formularios o las notificaciones).

\n
\n
\n

Ejercicios 6.16.-6.19.

\n

Ahora hagamos una nueva versión de la aplicación de anécdotas que use la librería TanStack Query. Usa este proyecto como punto de partida. El proyecto tiene un JSON Server instalado, la operación del cual se ha modificado ligeramente (Revisa el archivo server.js para más detalles. Asegúrate de estar conectándote al PORT correcto). Inicia el servidor con npm run server.

\n

Usa la Fetch API para hacer las peticiones.

\n

Ejercicio 6.16

\n

Implementa la obtención de anécdotas del servidor usando TanStack Query.

\n

La aplicación debe funcionar de tal manera que si hay problemas para comunicarse con el servidor, solo se mostrará una página de error:

\n\"navegador\n

Puedes encontrar aquí información sobre cómo detectar posibles errores.

\n

Puedes simular un problema con el servidor apagando el JSON Server. Ten en cuenta que en una situación problemática, la consulta primero está en el estado isLoading durante un tiempo, porque si una solicitud falla, TanStack Query intenta la solicitud varias veces antes de que indique que la solicitud no es exitosa. Opcionalmente, puedes especificar que no se realicen reintentos:

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

o que la solicitud se vuelva a intentar solo una vez más:

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

Ejercicio 6.17

\n

Implementa la adición de nuevas anécdotas al servidor usando TanStack Query. La aplicación debe renderizar una nueva anécdota por defecto. Ten en cuenta que el contenido de la anécdota debe tener al menos 5 caracteres de longitud, de lo contrario el servidor rechazará la solicitud POST. No tienes que preocuparte por el control de errores ahora.

\n

Ejercicio 6.18

\n

Implementa la votación de anécdotas usando nuevamente TanStack Query. La aplicación debe renderizar automáticamente el número aumentado de votos para la anécdota votada.

\n

Ejercicio 6.19

\n

Extrae los detalles de TanStack Query a un hook personalizado.

\n
\n
\n

Context API

\n

Volvamos a la conocida aplicación de contador. La aplicación se define de la siguiente manera:

\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

El componente App define el estado de la aplicación y se lo pasa a Display, que renderiza el valor del contador:

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

y al componente Controls, que renderiza los botones:

\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

La aplicación crece:

\n\n

El papel de App cambia: sigue conservando el estado, pero ya no renderiza directamente los componentes que lo utilizan:

\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

El nuevo componente Panel renderiza los componentes que muestran el contador y los botones:

\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

La jerarquía de componentes es la siguiente:

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

El estado continúa en App. Para que Display y Controls accedan al contador, tanto el estado como su función de actualización deben atravesar Panel como props, aunque Panel no los necesite. Esta situación aparece fácilmente al utilizar estado creado con useState y se denomina prop drilling.

\n

La Context API integrada en React ofrece una solución. Un contexto de React es una especie de estado global de la aplicación al que se puede dar acceso directo a cualquier componente.

\n

Creemos un contexto que almacene la gestión del estado del contador.

\n

El contexto se crea con createContext. Lo definiremos en el archivo src/CounterContext.jsx:

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

El componente App puede proporcionar el contexto a sus componentes hijos así:

\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

El contexto se proporciona envolviendo los componentes hijos con CounterContext.Provider y asignándole un valor adecuado.

\n

Su valor es ahora un objeto con los atributos counter y setCounter: el estado del contador y la función que lo actualiza.

\n

Como Panel ya no recibe props relacionadas con el contador, se simplifica:

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

Los demás componentes pueden acceder al contexto mediante el hook useContext. Display cambia de la siguiente manera:

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

Display ya no necesita props. Obtiene el contador llamando a useContext con el objeto CounterContext como parámetro.

\n

De forma análoga, Controls pasa a ser:

\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

Los componentes ya tienen acceso al contenido establecido por el proveedor: el estado del contador y su función de actualización.

\n

Extraen los atributos que necesitan mediante la desestructuración de JavaScript:

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

Definir el contexto del contador en su propio archivo

\n

La aplicación aún tiene un aspecto poco agradable: la gestión del estado del contador está definida dentro de App. Traslademos todo el código relacionado al archivo 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

El archivo exporta tanto CounterContext como CounterContextProvider, que es esencialmente un proveedor cuyo valor contiene el contador y su función de actualización.

\n

Utilicemos el proveedor directamente en 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

El contexto que define el valor y la funcionalidad del contador está ahora disponible para todos los componentes.

\n

App se simplifica:

\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

El contexto sigue utilizándose igual y los demás componentes no necesitan cambios. Por ejemplo, Controls permanece así:

\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

La solución es bastante buena. Todo el estado de la aplicación —el valor del contador— queda aislado en CounterContext. Cada componente accede exactamente a la parte que necesita mediante useContext y la desestructuración.

\n

Hagamos una pequeña mejora y definamos también las funciones increment, decrement y zero dentro del contexto:

\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

Ahora podemos usar las funciones obtenidas del contexto directamente como controladores de eventos:

\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

Todavía podemos mejorarlo. Al observar el uso del contexto, vemos el mismo código repetitivo en ambos componentes que lo consumen:

\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

Podemos avanzar un paso más creando un hook personalizado que devuelva directamente el contexto. Añadámoslo al archivo hooks/useCounter.js:

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

El uso del contexto queda aún más sencillo:

\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

La solución nos satisface. Aísla toda la gestión del estado dentro del contexto. Los componentes que lo usan desconocen cómo se implementa; gracias al hook personalizado, ni siquiera necesitan saber que la solución se basa en la Context API.

\n

El código de la aplicación está en el repositorio de GitHub https://github.com/fullstack-hy2020/context-counter.

\n
\n
\n

Ejercicios 6.20.-6.22.

\n

Ejercicio 6.20.

\n

La aplicación tiene un componente Notification para mostrar notificaciones al usuario.

\n

Implementa la gestión del estado de las notificaciones de la aplicación utilizando la Context API. La notificación debe informar al usuario cuando se crea una nueva anécdota o cuando se vota por ella:

\n\"navegador\n

La notificación se muestra durante cinco segundos.

\n

Ejercicio 6.21.

\n

Como se indicó en el ejercicio 6.17, el servidor exige que el contenido de la anécdota que se añade tenga al menos 5 caracteres. Implementa ahora el manejo de errores de la inserción. En la práctica basta con mostrar una notificación cuando falle la solicitud POST:

\n\"navegador\n

La condición de error debe manejarse en la función de callback registrada para ello, consulta aquí cómo registrar una función.

\n

Ejercicio 6.22.

\n

Si aún no lo has hecho, mueve el contexto de las notificaciones a su propio archivo NotificationContext.jsx, del mismo modo que el contexto de la aplicación del contador se trasladó a CounterContext.jsx. Crea también un hook personalizado useNotify que encapsule la lógica de las notificaciones. Simplifica los componentes que las utilizan para que llamen directamente al hook en lugar de llamar a useContext por separado.

\n

Este fue el último ejercicio para esta parte del curso y es hora de enviar tu código a GitHub y marcar todos tus ejercicios completados en el sistema de envío de ejercicios.

\n
\n
\n

¿Qué solución de gestión de estado elegir?

\n

En los capítulos 1-5, toda la gestión de estado de la aplicación se realizó utilizando el hook de React useState. Las llamadas asíncronas al backend requerían el uso del hook useEffect en algunas situaciones. En principio, no se necesita nada más.

\n

Un problema sutil con una solución basada en un estado creado con el hook useState es que si alguna parte del estado de la aplicación se necesita en varios componentes de la aplicación, el estado y las funciones para manipularlo deben pasarse via props a todos los componentes que manejan el estado. A veces, las props deben pasar por varios componentes, y los componentes a lo largo del camino pueden ni siquiera estar interesados en el estado de ninguna manera. Este fenómeno algo desagradable se llama prop drilling.

\n

A lo largo de los años, se han desarrollado varias soluciones alternativas para la gestión de estado de aplicaciones React, que se pueden usar para aliviar situaciones problemáticas (por ejemplo, prop drilling). Sin embargo, ninguna solución ha sido \"final\", todas tienen sus propias ventajas y desventajas, y se están desarrollando nuevas soluciones todo el tiempo.

\n

La situación puede confundir a un principiante e incluso a un desarrollador web experimentado. ¿Qué solución se debe usar?

\n

Para una aplicación simple, useState es sin duda un buen punto de partida. Si la aplicación está comunicándose con el servidor, la comunicación se puede manejar de la misma manera que en los capítulos 1-5, utilizando el estado de la aplicación misma. Sin embargo, recientemente se ha vuelto más común mover la comunicación y la gestión asociada del estado al menos parcialmente bajo el control de TanStack Query (o alguna otra librería similar). Si estás preocupado por useState y el prop drilling que conlleva, usar context puede ser una buena opción. También hay situaciones donde puede tener sentido manejar parte del estado con useState y parte con contextos.

\n

Durante mucho tiempo, la solución más popular y completa fue Redux, una forma de implementar la arquitectura Flux. Sin embargo, Redux es conocido por su complejidad y la abundancia de código repetitivo, lo que motivó la aparición de alternativas más recientes. En este curso Redux se ha sustituido por Zustand, que ofrece una funcionalidad equivalente con una API mucho más sencilla. Zustand se ha convertido en una opción popular cuando hace falta algo más que useState, pero toda la maquinaria de Redux resulta excesiva. Parte de las críticas a la rigidez de Redux han quedado obsoletas gracias a Redux Toolkit, y Redux todavía se usa mucho, especialmente en proyectos grandes.

\n

Ni Zustand ni Redux tienen que utilizarse en toda la aplicación. Por ejemplo, puede ser razonable gestionar fuera de ellos el estado de los formularios cuando no afecta al resto de la aplicación. También es perfectamente posible combinar Zustand o Redux con TanStack Query.

\n

La pregunta de qué solución de gestión de estado se debe usar no es para nada sencilla. Es imposible dar una sola respuesta correcta. También es probable que la solución de gestión de estado seleccionada pueda resultar ser subóptima a medida que la aplicación crece hasta tal punto que la solución tenga que cambiarse incluso si la aplicación ya ha sido puesta en uso de producción.

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