# Next.js для React-розробника: що треба знати перед співбесідою

> Навіщо фреймворк поверх React, чим відрізняються SSR, SSG, ISR і Server Components, як влаштовані роутинг і data fetching в App Router – і які питання про Next.js реально ставлять на співбесідах.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: React і Frontend
- Canonical: https://cookiesoftware.io/blog/nextjs-dlia-react-rozrobnyka

---

**Коротка відповідь.** Next.js – це фреймворк поверх React, який відповідає за те, чого в самому React немає: роутинг, рендеринг на сервері, збірку й оптимізації. Перед співбесідою достатньо впевнено розуміти чотири речі: навіщо він потрібен, чим відрізняються стратегії рендерингу (SSR/SSG/ISR + Server Components), як влаштований роутинг в App Router і як там працює data fetching. Зубрити конфігурації напам'ять не треба – треба вміти пояснити, коли і що обирати.

## Навіщо фреймворк поверх React

React – бібліотека для UI: компоненти, стан, рендеринг. Усе інше застосунку – маршрути, серверний рендеринг, розбиття бандла, оптимізація зображень і шрифтів, API-ендпоїнти – React свідомо не вирішує. Можна зібрати це самостійно з окремих інструментів, а можна взяти фреймворк, де це вже інтегровано й підтримується як єдине ціле.

Сама [документація React](https://react.dev/learn) рекомендує починати нові продакшн-застосунки з фреймворка. На співбесіді відповідь «Next.js дає роутинг, серверний рендеринг і збірку з коробки, тому команда не підтримує цю інфраструктуру сама» – коротка і достатня.

## Стратегії рендерингу простими словами

Головна тема будь-якої співбесіди про Next.js. Суть кожної стратегії – **коли і де генерується HTML**:

| Стратегія | Коли генерується HTML | Коли обирати |
|---|---|---|
| SSG (static) | Один раз під час build | Контент однаковий для всіх і змінюється з деплоєм: лендинги, блог, документація |
| ISR (incremental) | Під час build + перегенерація за інтервал або за запитом | Статика, яка оновлюється без редеплою: каталог товарів, новини |
| SSR (dynamic) | На кожен запит на сервері | Відповідь залежить від користувача чи моменту: кабінет, стрічка, пошук |
| CSR | У браузері після завантаження JS | Інтерактивні частини за логіном, де SEO неважливе: дашборди, редактори |

Питання-пастка: «що краще – SSR чи SSG?». Правильна відповідь – контрзапитання: чи однаковий контент для всіх користувачів і як часто він змінюється. Стратегія обирається на рівні сторінки, а не застосунку: у одному проєкті лендинг може бути статичним, а кабінет – динамічним.

## Server Components: у чому ідея

В App Router компоненти за замовчуванням **серверні**: вони виконуються тільки на сервері, їхній код не потрапляє в браузерний бандл, і вони можуть напряму читати дані (базу, файли, API). Клієнтськими стають лише компоненти з директивою `'use client'` – ті, яким потрібні стан, ефекти чи обробники подій.

Практичний наслідок, який варто озвучити на співбесіді: інтерактивність опускається якнайнижче по дереву. Сторінка-список – серверна, а клієнтський у ній лише пошуковий інпут. Менше клієнтського JS – швидше завантаження.

Типове уточнення від інтерв'юера: Server Components – це не SSR у старому сенсі. SSR рендерить HTML, але весь код компонентів усе одно їде в браузер для гідратації. Серверні компоненти в браузер не потрапляють узагалі.

## Роутинг і data fetching в App Router

Роутинг – файловий: структура папок в `app/` і є маршрутами.

```
app/
  page.tsx            →  /
  blog/
    page.tsx          →  /blog
    [slug]/page.tsx   →  /blog/:slug   (динамічний сегмент)
  layout.tsx          →  спільна обгортка, не перемонтовується між сторінками
```

Данні в серверних компонентах отримують просто через `async/await` – без ефектів і клієнтських хуків:

```tsx
// app/blog/[slug]/page.tsx – серверний компонент
export default async function ArticlePage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const article = await getArticle(slug); // прямий виклик на сервері
  return <Article data={article} />;
}
```

Для статичної генерації динамічних маршрутів є `generateStaticParams` – список slug-ів, які треба зрендерити під час build. Порівняй це з класичним клієнтським підходом «useEffect + fetch + стани завантаження» – і зможеш аргументовано пояснити різницю: менше водоспадів запитів, менше клієнтського коду, дані ближче до джерела.

## Типові питання співбесід – з відповідями

**– Чим SSG відрізняється від ISR?**
SSG генерує сторінку раз під час build; ISR – це той самий SSG, але сторінка може перегенеруватися після деплою: за таймером або за запитом. Обираю ISR, коли контент змінюється частіше, ніж хочеться деплоїти.

**– Коли компонент має бути клієнтським?**
Коли йому потрібні стан, ефекти, браузерні API або обробники подій. Усе інше лишаю серверним, щоб не роздувати бандл.

**– Де в Next.js жити API-логіці?**
Route handlers для публічних ендпоїнтів; для внутрішніх потреб сторінки часто достатньо прямого виклику з серверного компонента – окремий ендпоїнт не потрібен.

**– Як Next.js впливає на продуктивність?**
Автоматичне розбиття коду по маршрутах, оптимізація зображень і шрифтів, серверні компоненти без клієнтського JS. Але фреймворк не скасовує [профілювання React-частини](/blog/optymizatsiia-react-performance) – зайві ре-рендери лишаються твоєю відповідальністю.

## Кешування й ревалідація: мінімум, який треба розуміти

Друга за частотою тема після стратегій рендерингу. Ідея проста: статично згенерована сторінка – це кеш, і в нього мають бути правила оновлення.

```tsx
// Перегенерація сторінки не частіше ніж раз на годину (ISR)
export const revalidate = 3600;

// Або точково: перегенерувати після зміни даних
import { revalidatePath } from 'next/cache';
await revalidatePath('/blog');
```

На співбесіді достатньо пояснити різницю двох підходів: **за часом** (сторінка може бути застарілою до N секунд – прийнятно для каталогу) і **за подією** (оновили запис у CMS → зревалідували конкретний шлях – точніше, але потребує інтеграції). І назвати чесний компроміс: агресивне кешування = швидкість і дешевизна, слабке кешування = свіжість даних і більше навантаження.

## Мінімальний план підготовки за три вечори

1. **Вечір 1 – рендеринг.** Створи проєкт, зроби три сторінки: статичну, динамічну (SSR) і ISR з `revalidate`. Подивись у build-лог, як Next.js позначає кожну (static / dynamic). Поясни собі вголос, чому саме так.
2. **Вечір 2 – роутинг і дані.** Динамічний маршрут `[slug]` + `generateStaticParams` + async-сторінка з реальним запитом. Додай `loading.tsx` і `not-found.tsx` – і зрозумій, коли кожен показується.
3. **Вечір 3 – межа клієнт/сервер.** Візьми сторінку-список і додай до неї клієнтський пошук. Мета – усвідомити, чому `'use client'` стоїть на маленькому інпуті, а не на всій сторінці, і що станеться з бандлом, якщо зробити навпаки.

Після цих трьох вправ ти зможеш відповідати з власного досвіду, а не з чужих конспектів – різницю інтерв'юер чує з першої відповіді.

## Чого НЕ треба вчити напам'ять

- Точні назви конфіг-опцій і сигнатури API – це [документація](https://nextjs.org/docs), вона під рукою і в тебе, і в інтерв'юера.
- Відмінності всіх історичних версій Pages Router – достатньо знати, що App Router новіший і базується на Server Components; деталі легасі спитають лише там, де на ньому реально працюють.
- Внутрішню механіку збірки – якщо ти не подаєшся на роль в інфраструктурній команді.

Інвестуй час у розуміння **критеріїв вибору** (яка стратегія рендерингу і чому, що серверне, а що клієнтське) – саме це перевіряють. База залишається базою: без впевненого React жодні знання фреймворка не врятують, тому спершу пройдись по [гайду підготовки до React-співбесіди](/blog/react-interview-guide), а архітектурний рівень аргументації – у статті про [React-архітектуру для Senior](/blog/senior-react-architecture).