Načítání dat

Než začneme: opsaný ceník

Představ si kancelář, kde pět lidí potřebuje znát aktuální ceny od dodavatele. Každý si zavolá sám a opíše si ceník do svého bloku. Dodavatel dostane pět stejných telefonátů. Za týden dodavatel ceny změní – a v kanceláři je pět bloků se starými cenami, o kterých nikdo neví, že jsou staré.

Tohle je podstata dat ze serveru: nepatří ti. Máš jen jejich opis, který může kdykoli zastarat. Lokální stav (otevřené menu, text v poli) je tvůj sešit – víš přesně, co v něm je. Serverová data jsou opsaný ceník. Potřebují tedy něco, co lokální stav nezná:

• Jeden opis pro všechny – když se ptá pět komponent, zavolá se jednou (deduplikace) a výsledek se sdílí (cache).
• Vědět, kdy je opis starý – a obnovit ho (po čase, po návratu do okna, po změně).
• Přeškrtnout opis po změně – když sám něco změníš u dodavatele, starý opis už neplatí.
• Řešit závody odpovědí, opakování při chybě, stránkování…

Lepší kancelář má proto nástěnku se správcem. Kdo potřebuje ceník, podívá se na nástěnku. Správce dodavateli volá jen jednou, ví, jak starý je každý údaj, a když je potřeba, zavolá znovu. Takovým správcem je v Reactu knihovna TanStack Query.

1. Proč fetch v efektu nestačí

Z lekce o efektech umíš načíst uživatele takhle:

function UserName({ id }: { id: number }) {
  const [user, setUser] = useState<User | null>(null)

  useEffect(() => {
    let ignore = false
    fetchUser(id).then((u) => !ignore && setUser(u))
    return () => { ignore = true }
  }, [id])

  return <span>{user ? user.name : 'Načítám…'}</span>
}

Funguje to, ale každá komponenta je ten člověk s vlastním blokem:

• Když je na stránce UserName třikrát se stejným id, odejdou tři stejné požadavky.
• Když komponentu skryješ a znovu ukážeš, opis se zahodil – zase „Načítám…“ a další požadavek.
• Když se data na serveru změní, nikdo se to nedozví.
• A to jsme ještě neřešili chyby, opakování ani stránkování.

2. useQuery: správce nástěnky

// main.tsx – jednou pro celou aplikaci: zřídíme nástěnku
const queryClient = new QueryClient()
<QueryClientProvider client={queryClient}><App /></QueryClientProvider>

// kdekoli v aplikaci
function UserName({ id }: { id: number }) {
  const { data, isPending, isError, error } = useQuery({
    queryKey: ['user', id],           // štítek: co přesně chci
    queryFn: () => fetchUser(id),     // jak to získat, když to na nástěnce není
    staleTime: 60_000,                // minutu je údaj čerstvý
  })

  if (isPending) return <span>Načítám…</span>
  if (isError) return <span>{error.message}</span>
  return <span>{data.name}</span>
}

Co se děje, když se na stránce objeví tři UserName s id = 2:

1. První se zeptá správce na štítek ['user', 2]. Na nástěnce nic není → správce zavolá queryFn. Komponenta je ve stavu isPending.
2. Druhá a třetí se zeptají na stejný štítek. Správce ví, že už volá – nový požadavek neposílá, jen si je zapíše.
3. Odpověď přijde → správce ji vyvěsí na nástěnku a všem třem dá vědět. Všechny tři ukážou jméno.
4. Za pět minut se objeví čtvrtá. Údaj je na nástěnce, takže ho dostane okamžitě. Protože je starší než staleTime, správce ho zároveň na pozadí obnoví.

queryKey: štítek na šanonu

Podle štítku správce hledá data na nástěnce. Musí proto obsahovat všechno, na čem dotaz závisí. Ceník ovoce, strana 2 je jiný šanon než ceník zeleniny, strana 1:

useQuery({
  queryKey: ['products', { category, page }],     // ✅ změna kategorie nebo stránky = jiný šanon
  queryFn: () => fetchProducts({ category, page }),
})

useQuery({
  queryKey: ['products'],                         // ❌ všechny stránky by sdílely jeden šanon
  queryFn: () => fetchProducts({ category, page }),
})

3. Mutace a invalidace: změny na serveru

Když sám zavoláš dodavateli a objednáš změnu, víš, že opis ceníku na nástěnce už neplatí. Přeškrtneš ho, a správce sežene nový. Přesně tohle dělá dvojice useMutation + invalidateQueries:

function NewPost() {
  const queryClient = useQueryClient()

  const mutation = useMutation({
    mutationFn: createPost,                       // změna na serveru
    onSuccess: () => {
      // přeškrtni všechny šanony začínající 'posts'
      return queryClient.invalidateQueries({ queryKey: ['posts'] })
    },
  })

  return (
    <button onClick={() => mutation.mutate('Nový příspěvek')} disabled={mutation.isPending}>
      {mutation.isPending ? 'Ukládám…' : 'Přidat'}
    </button>
  )
}

1. mutation.mutate(…) zavolá createPost. Během čekání je isPending true.
2. Po úspěchu invalidateQueries označí šanony ['posts', …] za zastaralé – všechny stránky seznamu najednou.
3. Ty, které jsou právě na obrazovce, správce hned načte znovu. Ostatní až ve chvíli, kdy je někdo bude potřebovat.

4. Suspense a use(): čekárna s cedulí

V restauraci může každý stůl hlásit „ještě nemám polévku“, „ještě nemám hlavní jídlo“… Nebo celá sekce dostane ceduli „připravujeme, chvilku strpení“ a jídla se donesou, až jsou hotová. Druhý způsob je přehlednější – číšník řeší čekání na jednom místě.

Místo if (isPending) v každé komponentě můžeš čekání popsat jednou, o úroveň výš: obalit část stromu do <Suspense fallback>. Komponenty uvnitř pak data prostě „mají“.

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise)       // tady už máme data – žádné isPending, žádné undefined
  return <h2>{user.name}</h2>
}

<ErrorBoundary fallback={<p>Uživatel nenalezen</p>}>
  <Suspense fallback={<p>Připravujeme…</p>}>
    <UserProfile userPromise={getUser(id)} />
  </Suspense>
</ErrorBoundary>

1. use(userPromise) se podívá, jestli je Promise hotový. Pokud ne, komponenta řekne „ještě čekám“ a React ukáže nejbližší fallback.
2. Až se Promise vyřeší, React komponentu vykreslí znovu – a use tentokrát vrátí data.
3. Když Promise selže, chybu chytí nejbližší error boundary z minulé lekce.

Ověř si to

Rozcvička

VÝZVA: První useQuery

ProductNames zatím data nenačítá – data jsou prázdná.

1. Nahraď dva řádky s TODO jedním voláním:
     const { data, isPending } = useQuery({ queryKey: ['products'], queryFn: () => fetchProducts() })

Načítání i seznam jsou už napsané.

Výzvy

První výzva je přechod z kapitoly 1 do kapitoly 2: přepiš načítání z efektu na useQuery a přidej přednačtení. Druhá rozšíří kapitolu 3 o optimistickou změnu přímo na nástěnce – se zálohou pro případ, že server změnu odmítne.