Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Як Server Components кешують дані?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Server Components** у Next.js **кешують дані автоматично**, здебільшого через розумний `fetch`. **Ключове:** кеш працює на сервері й керується самим Next.js - за замовчуванням запити кешуються, а `cache: "no-store"` вимикає кеш, тоді як `revalidate` дає кеш з автооновленням.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняServer Components у Next.js **кешують дані автоматично**, здебільшого через розумний `fetch`. Кеш працює **на сервері** і керується самим Next.js - тобі не потрібно писати окрему логіку для цього. --- ## Базова ідея кешування Коли Server Component робить `fetch`, Next.js: 1. дивиться, **чи є вже результат цього запиту в кеші** 2. якщо є - **повертає його** 3. якщо немає - робить запит, зберігає результат і використовує далі За замовчуванням запити **кешуються**. --- ## Кешування через `fetch` ### Поведінка за замовчуванням ```js const res = await fetch("https://api.example.com/posts") ``` За замовчуванням це: - **кешований запит** - дані зберігаються - повторно використовуються при наступних рендерах - особливо ефективно для SSG та ISR Це відрізняється від звичайного `fetch` у браузері - тут він керується фреймворком. --- ## Керування кешем ### 1. Вимкнути кеш повністю Якщо дані мають бути **завжди свіжими**: ```js await fetch(url, { cache: "no-store" }) ``` Що це означає: - запит **не кешується** - виконується при кожному рендері - поведінка схожа на SSR --- ### 2. Кеш з оновленням (revalidation) Можна сказати: «кешуй, але онови раз на N секунд» ```js await fetch(url, { next: { revalidate: 60 } }) ``` Поведінка: - дані беруться з кешу - раз на 60 секунд Next.js оновлює їх у фоні - користувачі не чекають оновлення Це і є **ISR**, але на рівні конкретного запиту. --- ### 3. Кеш спільний для різних компонентів Якщо: - кілька Server Components роблять **однаковий fetch** - з однаковими параметрами Next.js: - виконає запит **один раз** - перевикористає результат Це знижує навантаження на API і прискорює рендер. --- ## Кеш і тип рендеру сторінки Кешування тісно пов'язане з тим, **як рендериться сторінка**: - **SSG** -> дані кешуються назавжди (або до revalidate) - **ISR** -> кеш + періодичне оновлення - **SSR (**`no-store`**)** -> кешу немає - **Client fetching** -> серверний кеш не бере участі --- ## Що саме кешується Кешується: - результат `fetch` - прив'язка до URL і опцій - дані, а не HTML Не кешується: - `useEffect` - клієнтські запити - запити з `no-store` --- ## Чому це зручно - не потрібно вручну писати Redis / memory cache - менше запитів до API - швидкі повторні рендери - поведінка передбачувана й декларативна Ти просто описуєш, **наскільки свіжими мають бути дані**, а Next.js робить решту. --- ## Коротке резюме - Server Components кешують дані через **серверний** `fetch` - за замовчуванням `fetch` **кешується** - `cache: "no-store"` - без кешу, завжди свіжі дані - `revalidate` - кеш з автооновленням - однакові запити перевикористовуються - кеш працює **на рівні даних**, а не UI Next.js бере на себе більшу частину логіки кешування - лишається лише обрати потрібну стратегію.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.