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

Los ejercicios de esta parte del curso difieren un poco de los anteriores. Como de costumbre, hay algunos ejercicios relacionados con la teoría de este capítulo. Los demás capítulos de esta parte no tienen ejercicios separados.

\n

Además, esta parte contiene una serie más amplia de ejercicios que amplía la aplicación BlogList creada en las partes 4 y 5. Puedes encontrar esos ejercicios aquí.

\n

Hooks de React

\n

React ofrece 18 hooks incorporados diferentes, de los cuales los más populares son useState y useEffect, que ya hemos utilizado extensivamente.

\n

En la parte 5 usamos useRef y useImperativeHandle, que permitieron que un componente proporcionara acceso a sus funciones a otros componentes. En la parte 6 utilizamos useContext para implementar un estado global.

\n

En los últimos años, los hooks se han convertido en la forma estándar en que las librerías exponen sus APIs. A lo largo del curso ya hemos visto varios ejemplos: Zustand proporciona useStore para acceder al estado global, React Router expone useNavigate y useParams para la navegación programática y el acceso a parámetros de la URL, y React Query ofrece useQuery y useMutation para gestionar el estado del servidor.

\n

Como se mencionó en la parte 1, los hooks no son funciones normales y cuando los usamos tenemos que cumplir con ciertas reglas o limitaciones. Recapitulemos las reglas del uso de hooks, copiadas literalmente de la documentación oficial de React:

\n

Evita utilizar Hooks dentro de loops, condicionales o funciones anidadas. En su lugar, utiliza los Hooks únicamente en el nivel superior de tu función de React.

\n

Los Hooks sólo deben ser utilizados durante la renderización de un componente de función en React:

\n\n

Existe un plugin de ESLint que se puede usar para verificar que la aplicación utiliza los hooks correctamente:

\n\"error\n

Además de los hooks que ya hemos utilizado, React proporciona varios hooks incorporados que merece la pena conocer. En esta sección veremos dos de ellos, useMemo y useCallback, ambos relacionados con la optimización del rendimiento. Después pasaremos a los hooks personalizados, que permiten empaquetar cualquier combinación de hooks en una función reutilizable propia.

\n

useMemo

\n

Cada vez que un componente de React se vuelve a renderizar, se ejecuta de nuevo todo el cuerpo de la función. Para la mayoría de los componentes esto no supone ningún problema, pero en ocasiones un componente realiza un cálculo costoso —como filtrar una lista grande, ordenar datos u obtener un valor complejo— y repetirlo en cada renderizado desperdicia tiempo.

\n

useMemo permite almacenar en caché el resultado de un cálculo entre renderizados. Recibe una función que realiza el cálculo y un array de dependencias. React solo vuelve a ejecutar la función cuando cambia alguna de las dependencias; en caso contrario, devuelve el resultado almacenado anteriormente.

\n

Consideremos un componente que renderiza una larga lista de elementos filtrados por un término de búsqueda:

\n
import { useState } from 'react'\n\nconst expensiveCalculation = () => {\n  let sum = 0\n  for (let i = 0; i < 100000; i++) sum += i\n  return sum\n}\n\nconst ITEMS = Array.from({ length: 10000 }, (_, i) => `item ${i + 1}`)\n\nconst FilteredList = () => {\n  const [filter, setFilter] = useState('')\n  const [darkMode, setDarkMode] = useState(false)\n\n  console.log('filtering...')\n  const filtered = ITEMS.filter(item => {\n    expensiveCalculation()\n    return item.includes(filter)\n  })\n\n  return (\n    <div style={{ background: darkMode ? '#333' : '#fff' }}>\n      <input\n        value={filter}\n        onChange={e => setFilter(e.target.value)}\n        placeholder=\"filter items\"\n      />\n      <button onClick={() => setDarkMode(!darkMode)}>toggle dark mode</button>\n      <ul>\n        {filtered.map(item => <li key={item}>{item}</li>)}\n      </ul>\n    </div>\n  )\n}\n\nexport default FilteredList
\n

Filtrar la lista lleva ahora tiempo, en parte gracias a la ralentización artificial que hemos introducido.

\n

El problema del componente es que al hacer clic en el botón del modo oscuro se vuelven a filtrar los 10 000 elementos aunque el texto del filtro no haya cambiado.

\n

Podemos solucionarlo con useMemo:

\n
import { useState, useMemo } from 'react'\nconst FilteredList = () => {\n  const [filter, setFilter] = useState('')\n  const [darkMode, setDarkMode] = useState(false)\n\n  const filtered = useMemo(() => {    console.log('filtering...')\n    return ITEMS.filter(item => {\n      expensiveCalculation()\n      return item.includes(filter)\n    })\n  }, [filter])\n  return (\n    <div style={{ background: darkMode ? '#333' : '#fff' }}>\n      //...\n    </div>\n  )\n}
\n

Con useMemo, el filtrado costoso solo se ejecuta cuando cambia filter. Alternar el modo oscuro únicamente actualiza el color de fondo y la lista filtrada almacenada en caché se devuelve de inmediato.

\n

El array de dependencias funciona exactamente igual que el de useEffect: React compara cada valor con el del renderizado anterior. Si todos los valores son idénticos, se reutiliza el valor memorizado. Si alguno difiere, la función se ejecuta de nuevo y el resultado se almacena para el siguiente renderizado.

\n

useMemo también puede utilizarse para memorizar objetos y arrays que se pasan como props, evitando renderizados innecesarios de componentes hijos que utilizan igualdad por referencia. Por ejemplo:

\n
const App = () => {\n  const [filter, setFilter] = useState('')\n\n  // Without useMemo, 'options' is a new object on every render even if filter hasn't changed\n  const options = useMemo(() => ({ caseSensitive: false, filter }), [filter])\n  return <SearchResults options={options} />\n}
\n

useMemo es una optimización del rendimiento; no deberías utilizarlo por defecto. La memorización prematura añade complejidad sin aportar beneficios cuando el cálculo es rápido. Mide primero y añade useMemo solo cuando hayas confirmado que un cálculo concreto constituye un cuello de botella.

\n

React.memo

\n

Mientras que useMemo almacena en caché el resultado de un cálculo dentro de un componente, React.memo adopta un enfoque diferente: almacena la salida renderizada de un componente completo. React.memo no es un hook, sino un componente de orden superior, y lo tratamos aquí porque complementa bien a useMemo. Cuando un componente está envuelto en React.memo, React omite su nuevo renderizado si sus props no han cambiado desde el renderizado anterior.

\n
const MyComponent = React.memo(({ value }) => {\n  console.log('rendered')\n  return <div>{value}</div>\n})
\n

Sin React.memo, MyComponent se vuelve a renderizar cada vez que lo hace su componente padre, aunque value sea el mismo. Con él, React compara las props anteriores y nuevas mediante una igualdad superficial y solo vuelve a renderizar cuando algo ha cambiado realmente.

\n

Ten en cuenta que React.memo solo comprueba las props. Si el componente utiliza un valor del contexto o su propio estado, seguirá renderizándose de nuevo cuando estos cambien.

\n

React.memo se combina de forma natural con useMemo: useMemo evita que se repitan cálculos costosos, mientras que React.memo impide que el propio componente vuelva a renderizarse.

\n

Si un componente memorizado recibe una nueva referencia a una función u objeto en cada renderizado, la memorización queda anulada. Aquí es donde entra en juego useCallback.

\n

useCallback

\n

Las funciones definidas dentro de un componente se vuelven a crear como objetos nuevos en cada renderizado. Normalmente esto es inofensivo, pero se convierte en un problema en dos situaciones concretas:

\n\n

useCallback resuelve este problema almacenando en caché la propia función entre renderizados y devolviendo el mismo objeto función mientras no cambien sus dependencias. Recibe una función y un array de dependencias, con una estructura idéntica a la de useMemo.

\n

Veamos un ejemplo concreto. Tenemos un componente NoteList costoso de renderizar, así que lo envolvemos en React.memo:

\n
// React.memo makes this component skip re-rendering if its props haven't changed\nconst NoteList = memo(({ onDelete, notes }) => {\n  console.log('NoteList rendered')\n  return (\n    <ul>\n      {notes.map(note => (\n        <li key={note.id}>\n          {note.content}\n          <button onClick={() => onDelete(note.id)}>delete</button>\n        </li>\n      ))}\n    </ul>\n  )\n})\n\nconst App = () => {\n  const [notes, setNotes] = useState([\n    { id: 1, content: 'Learn React' },\n    { id: 2, content: 'Learn hooks' },\n    { id: 3, content: 'Learn useMemo' },\n    { id: 4, content: 'Learn useCallback' },\n    { id: 5, content: 'Build something cool' },\n  ])\n  const [newNote, setNewNote] = useState('')\n\n  const handleDelete = (id) => {\n    setNotes(notes => notes.filter(note => note.id !== id))\n  }\n\n  const handleAdd = () => {\n    setNotes(notes => [...notes, { id: Date.now(), content: newNote }])\n    setNewNote('')\n  }\n\n  return (\n    <div>\n      <input value={newNote} onChange={e => setNewNote(e.target.value)} />\n      <button onClick={handleAdd}>add</button>\n      <NoteList notes={notes} onDelete={handleDelete} />\n    </div>\n  )\n}
\n

El problema es que handleDelete está definida como una función normal dentro de App. Cada vez que App se vuelve a renderizar —lo que ocurre con cada pulsación en el campo de la nueva nota— se crea un objeto función completamente nuevo y se pasa a NoteList como prop onDelete.

\n

Desde la perspectiva de React.memo, la prop ha cambiado, por lo que NoteList vuelve a renderizarse aunque la lista no haya cambiado:

\n\"muchos\n

Podemos solucionarlo con useCallback, que devuelve el mismo objeto función entre renderizados mientras sus dependencias no cambien:

\n
import { useState, useCallback, memo } from 'react'\n\n\nconst App = () => {\n  const [notes, setNotes] = useState([])\n  const [newNote, setNewNote] = useState('')\n\n  const handleDelete = useCallback((id) => {    setNotes(notes => notes.filter(note => note.id !== id))  }, []) // no external dependencies: this function never needs to change\n  // ...\n  return (\n    // ...\n  )\n}
\n

Ahora handleDelete es estable: React devuelve exactamente el mismo objeto función en cada renderizado, por lo que React.memo no detecta ningún cambio en la prop onDelete y omite por completo el nuevo renderizado de NoteList.

\n

Al igual que useMemo, utiliza useCallback solo cuando tengas un problema concreto, como un componente hijo memorizado que se renderiza innecesariamente o un useEffect que se ejecuta con demasiada frecuencia debido a una dependencia de función. Añadirlo en todas partes hace que el código sea más difícil de leer sin aportar ninguna mejora de rendimiento.

\n

Hooks personalizados

\n

React ofrece la opción de crear nuestros propios hooks personalizados. Según React, el propósito principal de los hooks personalizados es facilitar la reutilización de la lógica utilizada en los componentes.

\n
\n

Crear tus propios Hooks te permite extraer la lógica de los componentes en funciones reutilizables.

\n
\n

Los hooks personalizados son funciones normales de JavaScript que pueden utilizar cualquier otro hook, siempre que respeten las reglas de los hooks. Además, el nombre de los hooks personalizados debe comenzar con la palabra use.

\n

La idea clave es que cualquier lógica con estado que te encuentres duplicando entre componentes es candidata a extraerse a un hook personalizado. Cada llamada al mismo hook crea una porción de estado independiente. Esto es lo que distingue un hook personalizado de una función de utilidad corriente.

\n

Ya hemos implementado varios hooks personalizados en la parte 6. Los hooks useNotes y useNoteActions se crearon en la sección sobre Zustand, y useCounter se definió en la sección sobre React Query y Context.

\n

Hook de contador

\n

Implementamos una aplicación de contador en la parte 1, que puede tener su valor incrementado, reducido o reiniciado. El código de la aplicación es el siguiente:

\n
import { useState } from 'react'\n\nconst App = () => {\n  const [counter, setCounter] = useState(0)\n\n  return (\n    <div>\n      <div>{counter}</div>\n      <button onClick={() => setCounter(counter + 1)}>\n        plus\n      </button>\n      <button onClick={() => setCounter(counter - 1)}>\n        minus\n      </button>      \n      <button onClick={() => setCounter(0)}>\n        zero\n      </button>\n    </div>\n  )\n}
\n

Extraigamos la lógica del contador en su propio hook personalizado. El código del hook es el siguiente:

\n
const useCounter = () => {\n  const [value, setValue] = useState(0)\n\n  const increase = () => {\n    setValue(value + 1)\n  }\n\n  const decrease = () => {\n    setValue(value - 1)\n  }\n\n  const zero = () => {\n    setValue(0)\n  }\n\n  return {\n    value, \n    increase,\n    decrease,\n    zero\n  }\n}
\n

Nuestro hook personalizado utiliza el hook useState internamente para crear su propio estado. El hook devuelve un objeto, cuyas propiedades incluyen el valor del contador, así como funciones para manipular el valor.

\n

Los componentes de React pueden utilizar el hook como se muestra a continuación:

\n
const App = () => {\n  const counter = useCounter()\n\n  return (\n    <div>\n      <div>{counter.value}</div>\n      <button onClick={counter.increase}>\n        plus\n      </button>\n      <button onClick={counter.decrease}>\n        minus\n      </button>      \n      <button onClick={counter.zero}>\n        zero\n      </button>\n    </div>\n  )\n}
\n

Al hacer esto, podemos extraer el estado del componente App y su manipulación por completo en el hook useCounter. La gestión del estado y la lógica del contador ahora es responsabilidad del hook personalizado.

\n

El mismo hook podría reutilizarse en la aplicación que realizaba un seguimiento de la cantidad de clics realizados en los botones izquierdo y derecho:

\n
const App = () => {\n  const left = useCounter()\n  const right = useCounter()\n\n  return (\n    <div>\n      {left.value}\n      <button onClick={left.increase}>\n        left\n      </button>\n      <button onClick={right.increase}>\n        right\n      </button>\n      {right.value}\n    </div>\n  )\n}
\n

La aplicación crea dos contadores completamente separados. El primero se asigna a la variable left y el otro a la variable right. Cada llamada a useCounter crea su propia porción de estado independiente.

\n

Hooks personalizados y nuevos renderizados de componentes

\n

Una pregunta natural en este punto es: ¿cuándo se vuelve a renderizar realmente un componente que utiliza un hook personalizado?

\n

La respuesta es sencilla cuando se entiende qué es en realidad un hook personalizado. Desde la perspectiva del componente, un hook personalizado no es una entidad separada. Es simplemente una parte de la lógica del propio componente que se ha trasladado a una función independiente. Esto significa que todo el estado y los efectos definidos dentro del hook pertenecen al componente que lo llama, no al propio hook.

\n

En consecuencia, las reglas de renderizado son exactamente las mismas que con los hooks incorporados. El componente vuelve a renderizarse cuando cambia un estado gestionado dentro del hook, cuando cambia un valor de contexto al que el hook está suscrito o cuando cualquier hook al que el hook personalizado llama internamente provoca un nuevo renderizado.

\n

En cambio, acciones como reasignar variables normales dentro del hook o que cambien por sí solos los argumentos pasados al hook no provocan un nuevo renderizado.

\n

Los argumentos merecen un análisis más detallado. Pasar un nuevo valor a un hook no programa por sí mismo un nuevo renderizado, pero si el hook utiliza ese argumento como dependencia de un useEffect o un useMemo, el cambio hará que el efecto o el valor memorizado vuelvan a ejecutarse. Si esto, a su vez, llama a una función actualizadora del estado, el componente se renderizará de nuevo.

\n

Una forma útil de entenderlo es imaginar que copias y pegas todo el código del hook personalizado directamente dentro del componente. El comportamiento de renderizado sería idéntico. El hook solo sirve para organizar ese código; no es un límite que React trate de una manera especial.

\n
const useCounter = () => {\n  const [count, setCount] = useState(0) // this state belongs to the calling component\n  return { count, increment: () => setCount(c => c + 1) }\n}\n\nconst MyComponent = () => {\n  const { count, increment } = useCounter()\n  // re-renders whenever the count state inside the hook is updated\n}
\n

Hook para campos de formulario

\n

Tratar con formularios en React es algo complicado. La siguiente aplicación presenta al usuario un formulario que le solicita que ingrese su nombre, fecha de nacimiento y altura:

\n
const App = () => {\n  const [name, setName] = useState('')\n  const [born, setBorn] = useState('')\n  const [height, setHeight] = useState('')\n\n  return (\n    <div>\n      <form>\n        name: \n        <input\n          type='text'\n          value={name}\n          onChange={(event) => setName(event.target.value)} \n        /> \n        <br/> \n        birthdate:\n        <input\n          type='date'\n          value={born}\n          onChange={(event) => setBorn(event.target.value)}\n        />\n        <br /> \n        height:\n        <input\n          type='number'\n          value={height}\n          onChange={(event) => setHeight(event.target.value)}\n        />\n      </form>\n      <div>\n        {name} {born} {height} \n      </div>\n    </div>\n  )\n}
\n

Cada campo del formulario tiene su propio estado. Para mantener el estado del formulario sincronizado con los datos proporcionados por el usuario, tenemos que registrar un controlador onChange apropiado para cada uno de los elementos input. El patrón es idéntico para todos los campos; solo cambia el nombre de la variable de estado. Este es exactamente el tipo de repetición que los hooks personalizados están diseñados para eliminar.

\n

Definamos nuestro propio hook personalizado useField, que simplifica la gestión del estado del formulario:

\n
const useField = (type) => {\n  const [value, setValue] = useState('')\n\n  const onChange = (event) => {\n    setValue(event.target.value)\n  }\n\n  return {\n    type,\n    value,\n    onChange\n  }\n}
\n

La función de hook recibe el tipo de campo de entrada como parámetro. Devuelve todos los atributos requeridos por el input: su tipo, valor y el controlador onChange.

\n

El hook se puede utilizar de la siguiente manera:

\n
const App = () => {\n  const name = useField('text')\n  // ...\n\n  return (\n    <div>\n      <form>\n        <input\n          type={name.type}\n          value={name.value}\n          onChange={name.onChange} \n        /> \n        // ...\n      </form>\n// ...\n      <div>\n        {name.value} {born} {height}      </div>      \n    </div>\n  )\n}
\n

Propagación de atributos con spread

\n

Podríamos simplificar un poco más las cosas. Dado que el objeto name tiene exactamente todos los atributos que el elemento input espera recibir como props, podemos pasar los props al elemento usando la sintaxis spread(spread syntax) de la siguiente manera:

\n
<input {...name} />
\n

Como indica el ejemplo en la documentación de React, las siguientes dos formas de pasar props a un componente logran exactamente el mismo resultado:

\n
<Greeting firstName='Arto' lastName='Hellas' />\n\nconst person = {\n  firstName: 'Arto',\n  lastName: 'Hellas'\n}\n\n<Greeting {...person} />
\n

La aplicación se simplifica en el siguiente formato:

\n
const App = () => {\n  const name = useField('text')\n  const born = useField('date')\n  const height = useField('number')\n\n  return (\n    <div>\n      <form>\n        name: \n        <input  {...name} /> \n        <br/> \n        birthdate:\n        <input {...born} />\n        <br /> \n        height:\n        <input {...height} />\n      </form>\n      <div>\n        {name.value} {born.value} {height.value}\n      </div>\n    </div>\n  )\n}
\n

Tratar con formularios se simplifica enormemente cuando los desagradables detalles esenciales relacionados con la sincronización del estado del formulario se encapsulan dentro de nuestro hook personalizado.

\n

Persistencia del estado con un hook personalizado

\n

Los hooks personalizados pueden combinar varios hooks incorporados para encapsular comportamientos más complejos. Una funcionalidad que se necesita habitualmente es persistir el estado en localStorage para que sobreviva a una recarga de la página. El siguiente hook useLocalStorage envuelve useState y mantiene el valor sincronizado con localStorage:

\n
import { useState } from 'react'\n\nconst useLocalStorage = (key, initialValue) => {\n  const [storedValue, setStoredValue] = useState(() => {\n    try {\n      const item = window.localStorage.getItem(key)\n      return item ? JSON.parse(item) : initialValue\n    } catch (error) {\n      return initialValue\n    }\n  })\n\n  const setValue = (value) => {\n    try {\n      setStoredValue(value)\n      window.localStorage.setItem(key, JSON.stringify(value))\n    } catch (error) {\n      console.error(error)\n    }\n  }\n\n  return [storedValue, setValue]\n}
\n

El hook recibe una clave de almacenamiento y un valor inicial. En el primer renderizado lee el valor de localStorage y recurre a initialValue si todavía no hay nada almacenado. La función actualizadora que devuelve modifica al mismo tiempo tanto el estado de React como localStorage.

\n

Un componente que lo utiliza tiene exactamente el mismo aspecto que uno que emplea useState directamente:

\n
const App = () => {\n  const [name, setName] = useLocalStorage('name', '')\n\n  return (\n    <div>\n      <input value={name} onChange={e => setName(e.target.value)} />\n      <p>Hello, {name}! (your name is stored in localStorage)</p>\n    </div>\n  )\n}
\n

El componente no sabe que localStorage está implicado. Esa responsabilidad queda completamente oculta dentro del hook.

\n

Más sobre hooks

\n

Los hooks personalizados no son solo una herramienta para reutilizar código; también proporcionan una forma mejor de dividirlo en partes modulares más pequeñas.

\n

Internet está comenzando a llenarse con más y más material útil relacionado con los hooks. Vale la pena consultar las siguientes fuentes:

\n\n
\n
\n

Ejercicios 7.1.-7.6.

\n

Volvamos una vez más a trabajar con anécdotas. Utiliza como punto de partida para los ejercicios la aplicación del repositorio https://github.com/fullstack-hy2020/routed-anecdotes.

\n

Si clonas el proyecto dentro de un repositorio de Git existente, recuerda eliminar la configuración de Git de la aplicación clonada:

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

La aplicación se inicia de la forma habitual, pero antes debes instalar sus dependencias:

\n
npm install\nnpm run dev
\n

7.1: Hook useField

\n

Copia el hook personalizado useField en el archivo src/hooks/index.js. El hook debe gestionar el estado de un único campo de formulario y devolver un objeto con las siguientes propiedades: type, value y onChange.

\n

Si utilizas la exportación nombrada en lugar de la exportación predeterminada:

\n
import { useState } from 'react'\n\nexport const useField = (type) => {  const [value, setValue] = useState('')\n\n  const onChange = (event) => {\n    setValue(event.target.value)\n  }\n\n  return {\n    type,\n    value,\n    onChange\n  }\n}\n\n// modules can have several named exports\nexport const useAnotherHook = () => {  // ...\n}
\n

Luego, la importación ocurre de la siguiente manera:

\n
import  { useField } from './hooks'\n\nconst App = () => {\n  // ...\n  const username = useField('text')\n  // ...\n}
\n

Utiliza el hook en el formulario de creación de anécdotas.

\n

7.2: useField con reset

\n

Añade al formulario un botón que borre todos los campos de entrada:

\n\"formulario\n

Amplía el hook useField para que exponga una función reset que borre el valor del campo.

\n

Dependiendo de tu solución, es posible que veas la siguiente advertencia en tu consola:

\n\"consola\n

Volveremos a esta advertencia en el próximo ejercicio.

\n

7.3: Corrección del problema con spread

\n

Si tu solución no provocó que apareciera una advertencia en la consola, ya has terminado este ejercicio.

\n

Si ves la advertencia Invalid value for prop `reset` on <input> tag en la consola, realiza los cambios necesarios para eliminarla.

\n

El motivo de esta advertencia es que después de realizar los cambios en tu aplicación, la siguiente expresión:

\n
<input {...content}/>
\n

Esencialmente, es lo mismo que esto:

\n
<input\n  value={content.value} \n  type={content.type}\n  onChange={content.onChange}\n  reset={content.reset}/>
\n

El elemento input no debe recibir un atributo reset.

\n

Una solución simple sería no usar la sintaxis de spread y escribir todos los formularios de esta manera:

\n
<input\n  value={username.value} \n  type={username.type}\n  onChange={username.onChange}\n/>
\n

Si hiciéramos esto, perderíamos gran parte del beneficio proporcionado por el hook useField. En su lugar, busca una solución al problema, pero que aún sea fácil de usar con la sintaxis de spread.

\n

7.4: useAnecdotes, paso 1

\n

El proyecto ya tiene configurado un servidor JSON. Puedes iniciarlo con:

\n
npm run server
\n

Esto inicia un backend de JSON Server que expone la colección de anécdotas como un recurso REST en http://localhost:3001/anecdotes.

\n

El archivo existente services/anecdotes.js contiene las funciones necesarias para comunicarse con el backend, excepto la del último ejercicio. Ten en cuenta que el servicio utiliza la Fetch API en vez de Axios para las peticiones HTTP. Si no conoces Fetch, consulta la parte 6 antes de continuar.

\n

El patrón habitual para obtener datos de un servidor en React tiene este aspecto:

\n
import { useState, useEffect } from 'react'\nimport anecdoteService from './services/anecdotes'\n\nconst App = () => {\n  const [anecdotes, setAnecdotes] = useState([])\n\n  useEffect(() => {\n    anecdoteService.getAll().then(data => setAnecdotes(data))\n  }, [])\n\n  // ...\n}
\n

Implementa un hook personalizado useAnecdotes que encapsule esta comunicación con el servidor. Para este ejercicio basta con que el hook obtenga todas las anécdotas. La creación de nuevas anécdotas puede abordarse en el siguiente ejercicio.

\n

El hook debe utilizarse de esta forma:

\n
// ...\nimport { useAnecdotes } from './hooks'\nconst App = () => {\n  const { anecdotes } = useAnecdotes()\n  const addAnecdote = () => {} // a dummy function to keep code from breaking\n\n  return (\n    <Router>\n      <div>\n        <h1>Software anecdotes</h1>\n        <Menu />\n        <Routes>\n          <Route path=\"/\" element={<AnecdoteList anecdotes={anecdotes} />} />\n          <Route path=\"/create\" element={<CreateNew addAnecdote={addAnecdote} />} />\n          <Route path=\"/about\" element={<About />} />\n        </Routes>\n        <Footer />\n      </div>\n    </Router>\n  )\n}\n\nexport default App
\n

Una pista: antes se mencionó lo siguiente:

\n
\n

Una forma útil de entenderlo —es decir, de entender cómo funciona un hook— es imaginar que copias y pegas todo el código del hook personalizado directamente dentro del componente.

\n
\n

Ahora debes hacer, en cierto modo, lo contrario: copiar y pegar el código pertinente del componente en el hook. Esto incluye tanto useState como useEffect.

\n

7.5: useAnecdotes, paso 2

\n

Amplía el hook useAnecdotes para que también permita crear nuevas anécdotas. El hook debe exponer una función addAnecdote que envíe la nueva anécdota al servidor y actualice el estado local.

\n

Ahora el hook debe poder utilizarse así:

\n
const { anecdotes, addAnecdote } = useAnecdotes()
\n

Actualiza el componente App para pasar addAnecdote al componente CreateNew en lugar de la función provisional.

\n

7.6: useAnecdotes, paso 3

\n

Amplía el hook useAnecdotes con una función deleteAnecdote que elimine una anécdota del servidor y actualice el estado local. Añade un botón para eliminar junto a cada anécdota de la lista.

\n

Además, refactoriza la aplicación para que ni los datos de las anécdotas ni las funciones del hook se pasen como props. En su lugar, los componentes que los necesiten deben llamar directamente a useAnecdotes. Esto significa que App ya no tiene que actuar como intermediario pasando datos y callbacks por el árbol de componentes.

\n

Tras la refactorización, App debe tener este aspecto:

\n
const App = () => {\n  return (\n    <Router>\n      <div>\n        <h1>Software anecdotes</h1>\n        <Menu />\n        <Routes>\n          <Route path=\"/\" element={<AnecdoteList />} />\n          <Route path=\"/create\" element={<CreateNew />} />\n          <Route path=\"/about\" element={<About />} />\n        </Routes>\n        <Footer />\n      </div>\n    </Router>\n  )\n}
\n
","frontmatter":{"mainImage":{"publicURL":"/static/2184b1c35920cfc7a09e10660dea04eb/part-7.svg"},"part":7,"letter":"a","lang":"es"}}},"pageContext":{"part":7,"letter":"a","lang":"es"}},"staticQueryHashes":["3128451518"]}