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

Tarkastellaan osan lopussa vielä muutamaa erilaista tapaa sovelluksen tilan hallintaan.

\n

Jatketaan muistiinpano-sovelluksen parissa. Otetaan fokukseen palvelimen kanssa tapahtuva kommunikointi. Aloitetaan sovellus puhtaalta pöydältä. Ensimmäinen versio on seuraava:

\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

Alkuvaiheen koodi on GitHubissa repositorion https://github.com/fullstack-hy2020/query-notes branchissa part6-0.

\n

Palvelimella olevan datan hallinta TanStack Query ‑kirjaston avulla

\n

Hyödynnämme nyt TanStack Query ‑kirjastoa palvelimelta haettavan datan säilyttämiseen ja hallinnointiin.

\n

Asennetaan kirjasto komennolla

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

Tiedostoon main.jsx tarvitaan muutama lisäys, jotta kirjaston funktiot saadaan välitettyä koko sovelluksen käyttöö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

Käytetään aiemmista osista tuttuun tapaan JSON Serveriä simuloimaan backendin toimintaa. JSON Server on valmiiksi konfiguroituna esimerkkiprojektiin, ja projektin juuressa on tiedosto db.json, joka sisältää oletuksena kaksi muistiinpanoa. Voimme siis käynnistää serverin suoraan komennolla:

\n
npm run server
\n

Voimme nyt hakea muistiinpanot komponentissa App. Koodi laajenee seuraavasti:

\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

Datan hakeminen palvelimelta tapahtuu edellisen luvun tapaan Fetch APIn fetch-funktiolla. Funktiokutsu on kuitenkin nyt kääritty useQuery-funktiolla muodostetuksi kyselyksi. useQuery-funktiokutsun parametrina on olio, jolla on kentät queryKey ja queryFn. Kentän queryKey arvona on taulukko, joka sisältää merkkijonon notes. Se toimii avaimena määriteltyyn kyselyyn, eli muistiinpanojen listaan.

\n

Funktion useQuery paluuarvo on olio, joka kertoo kyselyn tilan. Konsoliin tehty tulostus havainnollistaa tilannetta:

\n\"browser\n

Eli ensimmäistä kertaa komponenttia renderöitäessä kysely on vielä tilassa pending, eli siihen liittyvä HTTP-pyyntö on kesken. Tässä vaiheessa renderöidään ainoastaan:

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

HTTP-pyyntö kuitenkin valmistuu niin nopeasti, että tekstiä eivät edes tarkkasilmäisimmät ehdi näkemään. Kun pyyntö valmistuu, renderöidään komponentti uudelleen. Kysely on toisella renderöinnillä tilassa success, ja kyselyolion kenttä data sisältää pyynnön palauttaman datan, eli muistiinpanojen listan, joka renderöidään ruudulle.

\n

Sovellus siis hakee datan palvelimelta ja renderöi sen ruudulle käyttämättä ollenkaan luvuissa 2-5 käytettyjä Reactin hookeja useState ja useEffect. Palvelimella oleva data on nyt kokonaisuudessaan TanStack Query ‑kirjaston hallinnoinnin alaisuudessa, ja sovellus ei tarvitse ollenkaan Reactin useState-hookilla määriteltyä tilaa!

\n

Siirretään varsinaisen HTTP-pyynnön tekevä funktio omaan tiedostoonsa 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

Komponentti App yksinkertaistuu nyt seuraavasti:

\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

Sovelluksen tämän hetken koodi on GitHubissa branchissa part6-1.

\n

Datan vieminen palvelimelle TanStack Queryn avulla

\n

Data haetaan jo onnistuneesti palvelimelta. Huolehditaan seuraavaksi siitä, että lisätty ja muutettu data tallennetaan palvelimelle. Aloitetaan uusien muistiinpanojen lisäämisestä.

\n

Tehdään tiedostoon requests.js funktio createNote uusien muistiinpanojen talletusta varten:

\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

Komponentti App muuttuu seuraavasti

\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

Uuden muistiinpanon luomista varten määritellään siis mutaatio funktion useMutation avulla:

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

Parametrina on tiedostoon requests.js lisäämämme funktio, joka lähettää Fetch APIn avulla uuden muistiinpanon palvelimelle.

\n

Tapahtumakäsittelijä addNote suorittaa mutaation kutsumalla mutaatio-olion funktiota mutate ja antamalla uuden muistiinpanon parametrina:

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

Ratkaisumme on hyvä. Paitsi se ei toimi. Uusi muistiinpano kyllä tallettuu palvelimelle, mutta se ei päivity näytölle.

\n

Jotta saamme renderöityä myös uuden muistiinpanon, meidän on kerrottava TanStack Querylle, että kyselyn, jonka avaimena on merkkijono notes, vanha tulos tulee mitätöidä eli\ninvalidoida.

\n

Invalidointi on onneksi helppoa, se voidaan tehdä kytkemällä mutaatioon sopiva onSuccess-takaisinkutsufunktio:

\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

Kun mutaatio on nyt suoritettu onnistuneesti, suoritetaan funktiokutsu

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

Tämä taas saa aikaan sen, että TanStack Query päivittää automaattisesti kyselyn, jonka avain on notes eli hakee muistiinpanot palvelimelta. Tämän seurauksena sovellus renderöi ajantasaisen palvelimella olevan tilan, eli myös lisätty muistiinpano renderöityy.

\n

Toteutetaan vielä muistiinpanojen tärkeyden muutos. Lisätään tiedostoon requests.js muistiinpanojen päivityksen hoitava funktio:

\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

Myös muistiinpanon päivittäminen tapahtuu mutaation avulla. Komponentti App laajenee seuraavasti:

\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

Eli jälleen luotiin mutaatio, joka invalidoi kyselyn notes, jotta päivitetty muistiinpano saadaan renderöitymään oikein. Mutaation käyttö on helppoa, funktio mutate saa parametrikseen muistiinpanon, jonka tärkeys on vaihdettu vanhan arvon negaatioon.

\n

Sovelluksen tämän hetken koodi on GitHubissa branchissa part6-2.

\n

Suorituskyvyn optimointi

\n

Sovellus toimii hyvin, ja koodikin on suhteellisen yksinkertaista. Erityisesti yllättää muistiinpanojen listan muutoksen toteuttamisen helppous. Esim. kun muutamme muistiinpanon tärkeyttä, riittää kyselyn notes invalidointi siihen, että sovelluksen data päivittyy:

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

Tästä on toki seurauksena se, että sovellus tekee muistiinpanon muutoksen aiheuttavan PUT-pyynnön jälkeen uuden GET-pyynnön, jonka avulla se hakee palvelimelta kyselyn datan:

\n\n

Jos sovelluksen hakema datamäärä ei ole suuri, ei asialla ole juurikaan merkitystä. Selainpuolen toiminnallisuuden kannaltahan ylimääräisen HTTP GET ‑pyynnön tekeminen ei juurikaan haittaa, mutta joissain tilanteissa se saattaa rasittaa palvelinta.

\n

Tarvittaessa on myös mahdollista optimoida suorituskykyä päivittämällä itse TanStack Queryn ylläpitämää kyselyn tilaa.

\n

Muutos uuden muistiinpanon lisäävän mutaation osalta on seuraavassa:

\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

Eli onSuccess-takaisinkutsussa ensin luetaan queryClient-olion avulla olemassaoleva kyselyn notes tila ja päivitetään sitä lisäämällä mukaan uusi muistiinpano, joka saadaan takaisinkutsufunktion parametrina. Parametrin arvo on funktion createNote palauttama arvo, jonka määriteltiin tiedostossa requests.js seuraavasti:

\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

Samankaltainen muutos olisi suhteellisen helppoa tehdä myös muistiinpanon tärkeyden muuttavaan mutaatioon, jätämme sen kuitenkin vapaaehtoiseksi harjoitustehtäväksi.

\n

Kiinnitetään lopuksi huomio erikoiseen yksityiskohtaan. TanStack Query hakee kaikki muistiinpanot uudestaan, jos siirrymme selaimessa toiselle välilehdelle ja sen jälkeen palaamme sovelluksen välilehdelle. Tämän voi havaita Developer Consolen network-välilehdeltä:

\n\n

Mistä on kyse? Hieman dokumentaatiota\ntutkimalla huomataan, että TanStack Queryn kyselyjen oletusarvoinen toiminnallisuus on se, että kyselyt (joiden tila on stale) päivitetään kun window focus vaihtuu. Voimme halutessamme kytkeä toiminnallisuuden pois luomalla kyselyn seuraavasti:

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

Konsoliin tehtävillä tulostuksilla voit tarkkailla sitä miten usein TanStack Query aiheuttaa sovelluksen uudelleenrenderöinnin. Nyrkkisääntönä on se, että uudelleenrenderöinti tapahtuu vähintään aina kun sille on tarvetta, eli kun kyselyn tila muuttuu. Voit lukea lisää asiasta esim. täältä.

\n

useNotes custom hook

\n

Ratkaisumme on aika hyvä, hieman häiritsevää on kuitenkin se, että paljon Tanstack Queryn yksityiskohtiin liittyviä määrittelyjä on tehty React-komponentissa. Eristetään nämä vielä omaan custom hook -funktioonsa:

\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

Hook-funktio siis kapseloi sisälleen kaiken TanStack Queryyn liittyvän: kyselyn muistiinpanojen hakemiseen sekä molemmat mutaatiot muistiinpanojen luomiseen ja päivittämiseen. Hookin käyttäjälle nämä yksityiskohdat ovat piilossa, sillä funktio palauttaa yksinkertaisen olion, jossa on

\n\n

Komponentti App yksinkertaistuu huomattavasti:

\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

Sovelluksen lopullinen koodi on GitHubissa branchissa part6-3.

\n

TanStack Query on monipuolinen kirjasto joka jo nyt nähdyn perusteella yksinkertaistaa sovellusta. Tekeekö TanStack Query monimutkaisemmat tilanhallintaratkaisut kuten esim. Zustandin tarpeettomaksi? Ei. TanStack Query voi joissain tapauksissa korvata osin sovelluksen tilan, mutta kuten dokumentaatio toteaa

\n\n

TanStack Query on siis kirjasto, joka ylläpitää frontendissä palvelimen tilaa, eli toimii ikäänkuin välimuistina sille, mitä palvelimelle on talletettu. TanStack Query yksinkertaistaa palvelimella olevan datan käsittelyä, ja voi joissain tapauksissa eliminoida tarpeen sille, että palvelimella oleva data haettaisiin frontendin tilaan. Useimmat React-sovellukset tarvitsevat palvelimella olevan datan tilapäisen tallettamisen lisäksi myös jonkun ratkaisun sille, miten frontendin muu tila (esim. lomakkeiden tai notifikaatioiden tila) käsitellään.

\n
\n
\n

Tehtävät 6.16.-6.19.

\n

Tehdään nyt anekdoottisovelluksesta uusi, TanStack Query ‑kirjastoa hyödyntävä versio. Ota lähtökohdaksesi täällä oleva projekti. Projektissa on valmiina asennettuna JSON Server, jonka toimintaa on hieman modifioitu. Käynnistä palvelin komennolla npm run server.

\n

Käytä pyyntöjen tekemiseen Fetch APIa.

\n

Tehtävä 6.16

\n

Toteuta anekdoottien hakeminen palvelimelta TanStack Queryn avulla.

\n

Sovelluksen tulee toimia siten, että jos palvelimen kanssa kommunikoinnissa ilmenee ongelmia, tulee näkyviin ainoastaan virhesivu:

\n\n

Löydät ohjeen virhetilanteen havaitsemiseen täältä.

\n

Voit simuloida palvelimen kanssa tapahtuvaa ongelmaa esim. sammuttamalla JSON Serverin. Huomaa, että kysely on ensin jonkin aikaa tilassa isPending sillä epäonnistuessaan TanStack Query yrittää pyyntöä muutaman kerran ennen kuin se toteaa, että pyyntö ei onnistu. Voit halutessasi määritellä, että uudelleenyrityksiä ei tehdä:

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

tai, että pyyntöä yritetään uudelleen esim. vain kerran:

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

Tehtävä 6.17

\n

Toteuta uusien anekdoottien lisääminen palvelimelle TanStack Queryn avulla. Sovelluksen tulee automaattisesti renderöidä lisätty anekdootti. Huomaa, että anekdootin sisällön pitää olla vähintään 5 merkkiä pitkä, muuten palvelin ei hyväksy POST pyyntöä. Virheiden käsittelystä ei tarvitse nyt välittää.

\n

Tehtävä 6.18

\n

Toteuta anekdoottien äänestäminen hyödyntäen jälleen TanStack Queryä. Sovelluksen tulee automaattisesti renderöidä äänestetyn anekdootin kasvatettu äänimäärä.

\n

Tehtävä 6.19

\n

Eriytä TanStack Queryn yksityiskohdat custom hook -funktioon.

\n
\n
\n

Context API

\n

Palataan vielä vanhaan kunnon laskurisovellukseen. Sovellus on määritelty seuraavasti

\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

Komponentti App siis määrittelee sovelluksen tilan, jonka se välittää laskurin arvon näyttävälle komponentille Display

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

sekä napit renderöivälle komponentille Controls:

\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

Sovellus kasvaa:

\n\n

Komponentin App rooli muuttuu, se säilyttää edelleen sovelluksen tilan, mutta ei enää itse renderöi suoraan laskurin tilaa käyttäviä komponentteja:

\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

Uuden komponentin Panel vastuulle tulee laskurin näytöstä ja napeista huolehtivien komponenttien renderöinti:

\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

Sovelluksen komponenttihierarkia on siis seuraava:

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

Sovelluksen tila on siis edelleen komponentissa App. Jotta laskurin tilaan päästään käsiksi komponenteissa Display ja Controls, välitetään tila ja sen muutosfunktio propseina komponentin Panel kautta, vaikka komponentti ei itse tilaa tarvitse. Vastaavanlaisia tilanteita syntyy helposti kun käytetään hookilla useState muodostettua tilaa. Ilmiöstä käytetään nimitystä prop drilling.

\n

Reactin sisäänrakennettu Context API tuo tilanteeseen ratkaisun. Reactin konteksti on eräänlainen sovelluksen globaali tila, johon on mahdollista antaa suora pääsy mille tahansa komponentille.

\n

Luodaan sovellukseen nyt konteksti, joka tallettaa laskurin tilanhallinnan.

\n

Konteksti luodaan Reactin hookilla createContext. Luodaan konteksti tiedostoon src/CounterContext.jsx:

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

Komponentti App voi nyt tarjota kontekstin sen alikomponenteille seuraavasti:

\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

Kontekstin tarjoaminen siis tapahtuu käärimällä lapsikomponentit komponentin CounterContext.Provider sisälle ja asettamalla kontekstille sopiva arvo.

\n

Kontekstin arvoksi annetaan nyt olio, jolla on attribuutit counter ja setCounter, eli laskurin tila ja sitä muuttava funktio.

\n

Huomioinarvoista on nyt se, että komponentille Panel ei enää välitetä laskurin tilaan liittyviä propseja, eli komponentti pelkistyy muotoon

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

Muut komponentit saavat nyt kontekstin käyttöön hookin useContext avulla. Display-komponentti muuttuu seuraavasti:

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

Display-komponentti ei siis tarvitse enää propseja, vaan se saa laskurin arvon käyttöönsä kutsumalla useContext-hookia, jolle se antaa parametriksi CounterContext-olion.

\n

Vastaavasti Controls-komponentti muuttuu muotoon:

\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

Komponentit saavat siis näin tietoonsa kontekstin tarjoajan siihen asettaman sisällön, eli laskurin tilan sekä sen arvoa muuttavan funktion.

\n

Komponentit ottavat käyttöönsä tarvitsemansa attribuutit käyttäen hyödykseen JavaScriptin destrukturointisyntaksia:

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

Laskurikontekstin määrittely omassa tiedostossa

\n

Sovelluksessamme on vielä sellainen ikävä piirre, että laskurin tilanhallinnan toiminnallisuus on määritelty komponentissa App. Siirretään nyt kaikki laskuriin liittyvä tiedostoon 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

Tiedosto eksporttaa nyt kontekstia vastaavan olion CounterContext lisäksi komponentin CounterContextProvider joka on käytännössä kontekstin tarjoaja (context provider), jonka arvona on laskuri ja sen tilan asettava funktio.

\n

Otetaan kontekstin tarjoaja käyttöön suoraan tiedostossa 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

Nyt laskurin arvon ja toiminnallisuuden määrittelevä konteksti on kaikkien sovelluksen komponenttien käytettävissä.

\n

Komponentti App yksinkertaistuu seuraavaan muotoon:

\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

Kontekstia käytetään edelleen samalla tavalla, eikä muihin komponentteihin tarvita muutoksia, eli esim. Controls on edelleen muotoa

\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

Ratkaisu on varsin hyvä. Koko sovelluksen tila eli laskurin arvo on nyt eristetty tiedostoon CounterContext. Komponentit saavat käyttöönsä juuri tarvitsemansa osan kontekstia useContext-hookia ja JavaScriptin destrukturointi-syntaksia käyttäen.

\n

Tehdään vielä pieni parannus, ja määritellään myös laskurin arvoa muuttavat funktiot increment, decrement ja zero kontekstissa:

\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

Nyt voimme käyttää nappien tapahtumankäsittelijöinä suoraan kontekstista saatuja funktiota:

\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

Parantamisen varaa on vielä erään asian suhteen. Jos tarkastelemme laskurikontekstin käyttöönottoa, huomaamme, että sama toimistuu molemmissa sitä käyttävissä komponenteissa:

\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

Voimme viedä ratkaisun aseleen pidemmälle muodostamalla custom hookin, joka palauttaa suoraan oikean kontekstin. Lisätään se tiedostoon hooks/useCoutet.js:

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

Kontekstin käyttöönotto on nyt yhden askeleen helpompaa:

\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

Olemme tyytyväisiä ratkaisuun, se eristää tilan käsittelyn kokonaisuudessaan kontekstiin. Tilaa käyttävät komponentit eivät ole millään tavalla tietoisia siitä miten tila on toteutettu, custom hookin ansioista ne eivät oikeastaan edes ole tietoisia siitä että ratkaisu perustuu Context API:n käyttöön.

\n

Sovelluksen koodi on GitHubissa repositoriossa https://github.com/fullstack-hy2020/context-counter.

\n
\n
\n

Tehtävät 6.20.-6.22.

\n

Tehtävä 6.20.

\n

Sovelluksessa on valmiina komponentti Notification käyttäjälle tehtävien notifikaatioiden näyttämistä varten.

\n

Toteuta sovelluksen notifikaation tilan hallinta Context API:n avulla. Notifikaatio kertoo kun uusi anekdootti luodaan tai anekdoottia äänestetään:

\n\n

Notifikaatio näytetään viiden sekunnin ajan.

\n

Tehtävä 6.21.

\n

Kuten tehtävässä 6.17 todettiin, palvelin vaatii, että lisättävän anekdootin sisällön pituus on vähintään 5 merkkiä. Toteuta nyt lisäämisen yhteyteen virheenkäsittely. Käytännössä riittää, että näytät epäonnistuneen lisäyksen yhteydessä käyttäjälle notifikaation:

\n\n

Virhetilanne kannattaa käsitellä sille rekisteröidyssä takaisinkutsufunktiossa, ks täältä miten rekisteröit funktion.

\n

Tehtävä 6.22.

\n

Jos et jo niin tehnyt, siirrä notifikaatioon liittyvä konteksti omaan tiedostoonsa NotificationContext.jsx, samaan tapaan kuin laskurisovelluksessa konteksti siirrettiin tiedostoon CounterContext.jsx. Luo myös custom hook useNotify, joka kapseloi notifikaatioon liittyvän logiikan. Yksinkertaista notifikaatiota käyttäviä komponentteja siten, että ne käyttävät hookia suoraan sen sijaan, että kutsuvat useContextia erikseen.

\n

Tämä oli osan viimeinen tehtävä ja on aika pushata koodi GitHubiin sekä merkata tehdyt tehtävät palautussovellukseen.

\n
\n
\n

Tilanhallintaratkaisun valinta

\n

Osissa 1-5 kaikki sovelluksen tilanhallinta hoidettiin Reactin hookin useState avulla. Backendiin tehtävät asynkroniset kutsut edellyttivät joissain tilanteissa hookin useEffect käyttöä. Mitään muuta ei periaatteessa tarvita.

\n

Hienoisena ongelmana useState-hookilla luotuun tilaan perustuvassa ratkaisussa on se, että jos jotain osaa sovelluksen tilasta tarvitaan useissa sovelluksen komponenteissa, tulee tila ja sen muuttamiseksi tarvittavat funktiot välittää propsien avulla kaikille tilaa käsitteleville komponenteille. Joskus propseja on välitettävä usean komponentin läpi, ja voi olla, että matkan varrella olevat komponentit eivät edes ole tilasta millään tavalla kiinnostuneita. Tästä hieman ikävästä ilmiöstä käytetään nimitystä prop drilling.

\n

Aikojen saatossa React-sovellusten tilanhallintaan on kehitelty muutamiakin vaihtoehtoisia ratkaisuja, joiden avulla ongelmallisia tilanteita (esim. prop drilling) saadaan helpotettua. Mikään ratkaisu ei kuitenkaan ole ollut \"lopullinen\", kaikilla on omat hyvät ja huonot puolensa, ja uusia ratkaisuja kehitellään koko ajan.

\n

Aloittelijaa ja kokenuttakin web-kehittäjää tilanne saattaa hämmentää. Mitä ratkaisua tulisi käyttää?

\n

Yksinkertaisessa sovelluksessa useState on varmasti hyvä lähtökohta. Jos sovellus kommunikoi palvelimen kanssa, voi kommunikoinnin hoitaa lukujen 1-5 tapaan itse sovelluksen tilaa hyödyntäen. Viime aikoina on kuitenkin yleistynyt se, että kommunikointi ja siihen liittyvä tilanhallinta siirretään ainakin osin TanStack Queryn (tai jonkun muun samantapaisen kirjaston) hallinnoitavaksi. Jos useState ja sen myötä aiheutuva prop drilling arveluttaa, voi kontekstin käyttö olla hyvä vaihtoehto. On myös tilanteita, joissa osa tilasta voi olla järkevää hoitaa useStaten ja osa kontekstien avulla.

\n

Pitkään suosituin kattavin tilanhallintaratkaisu on ollut Redux, joka on eräs tapa toteuttaa ns. Flux-arkkitehtuuri. Redux on kuitenkin tunnettu monimutkaisuudestaan ja runsaasta boilerplate-koodistaan, mikä on ollut motivaationa uudemmille tilanhallintaratkaisuille. Kurssimateriaalissa Redux onkin korvattu Zustand-kirjastolla, joka tarjoaa vastaavan toiminnallisuuden huomattavasti yksinkertaisemmalla rajapinnalla. Zustand on noussut suosituksi vaihtoehdoksi erityisesti silloin, kun tarvitaan enemmän kuin mitä useState tarjoaa, mutta Reduxin täysi koneisto tuntuu ylimitoitetulta. Osa Reduxin jäykkyyteen kohdistuvasta kritiikistä tosin on vanhentunut Redux Toolkit:in ansiosta, ja Redux on edelleen laajasti käytössä erityisesti suuremmissa projekteissa.

\n

Myöskään Zustandia tai Reduxia ei ole pakko käyttää sovelluksessa kokonaisvaltaisesti. Saattaa olla mielekästä hoitaa esim. sovellusten lomakkeiden datan tallentaminen niiden ulkopuolella, erityisesti niissä tilanteissa, missä lomakkeen tila ei vaikuta muuhun sovellukseen. Myös Zustandin tai Reduxin ja TanStack Queryn yhteiskäyttö samassa sovelluksessa on täysin mahdollista.

\n

Kysymys siitä mitä tilanhallintaratkaisua tulisi käyttää ei ole ollenkaan suoraviivainen. Yhtä oikeaa vastausta on mahdotonta antaa, ja on myös todennäköistä, että valittu tilanhallintaratkaisu saattaa sovelluksen kasvaessa osoittautua siinä määrin epäoptimaaliseksi, että tilanhallinnan ratkaisuja täytyy vaihtaa vaikka sovellus olisi jo ehditty viedä tuotantokäyttöön.

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