Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Як SSR працює з маршрутизацією SPA?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)При SSR сервер обробляє **перший запит**, визначає маршрут, рендерить HTML і надсилає його браузеру, а після гідрації всі наступні переходи виконує **клієнтський роутер**, без перезавантаження сторінки. **Ключове:** оновлення сторінки чи прямий перехід за URL знову викликають SSR на сервері, тоді як переходи по посиланнях усередині застосунку обробляються повністю на клієнті.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## 1. Що робить маршрутизація в SPA У **класичному SPA** (без SSR): - Сервер завжди віддає той самий файл - `index.html`. - У ньому завантажується JS-бандл (наприклад, React Router). - При переходах між сторінками браузер **не робить нових запитів на сервер**, а просто змінює URL і рендерить інший компонент. Сервер взагалі **не знає** про маршрути - усе робить клієнт. --- ## 2. Що додає SSR При **SSR** сервер знову стає учасником процесу: 1. Користувач запитує `/about`. 2. Сервер **визначає маршрут** (`/about` → компонент `<About />`). 3. Сервер **рендерить HTML** цієї сторінки і надсилає готову розмітку. 4. Після завантаження JS клієнт **"гідрує"** застосунок, і маршрутизація продовжує працювати вже як у SPA. > Ідея проста: > - перший маршрут (перший запит) рендериться **на сервері**, > - усі наступні переходи - **на клієнті**. --- ## 3. Детально: як SSR і SPA-роутинг взаємодіють ### Етап 1: Перший запит (server-side routing) - Браузер робить запит на `/products/42`. - Сервер (наприклад, Next.js) визначає: цей маршрут відповідає компоненту `<ProductPage id={42}>`. - Виконує SSR → генерує HTML → надсилає його браузеру. Користувач бачить уже готову сторінку (SSR-HTML). --- ### Етап 2: Hydration (оживлення) - Після отримання HTML браузер завантажує JS-бандли маршрутів. - React (чи інший фреймворк) гідрує сторінку - прив'язує обробники, стан, ініціалізує роутер. - З цього моменту **працює клієнтська маршрутизація**. --- ### Етап 3: Клієнтські переходи (client-side routing) - Користувач клікає по посиланню `<Link to="/contact">Контакти</Link>`. - Роутер (наприклад, React Router, Next.js router) **перехоплює клік**. - Замість запиту на сервер: - оновлюється історія (`history.pushState()`), - завантажується потрібний компонент (`<ContactPage />`), - і він рендериться без перезавантаження сторінки. Сервер уже не бере участі - усе робить JS у браузері. --- ## 4. SSR при оновленні або прямому переході Якщо користувач: - оновлює сторінку (`F5`), - або заходить напряму за адресою `/contact`, сервер знову має відрендерити потрібну сторінку, бо браузер робить **новий HTTP-запит**. > Таким чином, SSR-роутинг і SPA-роутинг працюють як дзеркала: > > - Сервер обслуговує **первинний запит**. > - Клієнт обробляє **навігацію всередині застосунку**. --- ## 5. Як це реалізовано у фреймворках ### **Next.js** - Кожна сторінка (`app/about/page.tsx` чи `pages/about.tsx`) - окремий маршрут. - При першому запиті SSR відмальовує компонент сторінки. - Після гідрації `next/router` працює як SPA-роутер - переходи миттєві. ```javascript import Link from 'next/link'; export default function Nav() { return ( <nav> <Link href="/">Головна</Link> <Link href="/about">Про нас</Link> </nav> ); } ``` Перший перехід на `/about` іде через сервер, а кліки по `<Link>` - через клієнтський роутинг. --- ### **Remix / React Router 6.4+** - Сервер і клієнт використовують **той самий роутер**. - На сервері `createStaticHandler()` готує дані й рендерить HTML. - На клієнті `createBrowserRouter()` бере ті самі маршрути й продовжує SPA-навігацію. --- ## 6. Переваги такого підходу | Перевага | Пояснення | |---|---| | Швидке перше завантаження | SSR віддає HTML миттєво | | Без перезавантаження при переходах | Після гідрації працює SPA | | SEO-оптимізація | Пошуковик бачить готовий HTML | | Покращений UX | Навігація плавна, як у нативних застосунках | | Універсальна маршрутизація | Один набір маршрутів працює і на сервері, і на клієнті | --- ## 7. Потенційні складнощі | Проблема | Опис | |---|---| | Потрібно синхронізувати роутер | Один і той самий роутинг має працювати на сервері й клієнті | | Повільний SSR-рендер блокує TTFB | Потрібно використовувати Streaming SSR | | Помилки при гідрації маршрутів | Різний стан на сервері й клієнті → mismatch | | Auth-маршрути | Перевірка прав доступу має працювати і на сервері, і на клієнті | --- ## Підсумок **SSR і SPA-роутинг працюють спільно:** | Етап | Хто обробляє | Що робить | |---|---|---| | Перший запит | Сервер | Рендерить HTML обраного маршруту | | Завантаження JS | Клієнт | Виконує гідрацію й ініціалізує роутер | | Подальші переходи | Клієнт | Змінює маршрути без перезавантаження | | Оновлення сторінки | Сервер | Знову виконує SSR | > SSR відповідає за **перший рендер**, > а SPA-роутинг - за **навігацію після гідрації**.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.