React Server Components: Vocabulary for Modern Frontend Development (англійською)

React Server Components (RSC) представив нову ментальну модель — і новий словник — для архітектури фронтенду. Незалежно від того, чи ви беруте участь у співбесіді на посаду старшого фахівця з інтерфейсу, переглядаєте PR Next.js або пояснюєте стратегію відтворення колегі з бекенду, точна термінологія RSC демонструє майстерність сучасного React.

---

Компонентна модель

** Компонент сервера ** Компонент React, який відтворює лише на сервері. Він має безпосередній доступ до баз даних, файлових систем і змінних середовища. Він не може використовувати гачки, такі як useState або useEffect, і не може обробляти події браузера. Компоненти сервера є типовими у маршрутизаторі програм Next. js. Фраза: “Список продуктів є компонентом сервера — він отримує дані безпосередньо з бази даних, не показуючи клієнту унікальних даних.”

** Компонент клієнта ** Компонент, який може використовувати API переглядача, гачки React і обробники подій. Позначено директивою 'use client' у верхній частині файла. Компоненти клієнта можна відтворювати і на сервері (для початкового HTML), але їх гідрування відбувається на клієнті. Фраза: “Смужка пошуку є компонентом клієнта, оскільки вона потребує useState для керування вхідним значенням.”

** директива « use client » ** Рядок 'use client' у верхній частині файла, який позначає компонент (і всі елементи, які він імпортує) як код з боку клієнта. Фраза: “Додання ‘use client’ до модального компонента, що витягнуто з великої бібліотеки анімації — перевірте розмір збірки.”

** директива « use server » ** Позначає функцію як * Дію сервера * — функцію на стороні сервера, яку можна викликати безпосередньо з компонентів клієнта, зазвичай, для надсилання або зміни форм. Фраза: “Форма використовує Дію Сервера, позначене як ‘використовувати сервер’ — не потрібний маршрут API.”

---

Рендрування і доставка

Гидратація Процес, за допомогою якого React додає слухачів подій і стан до статичного HTML, надісланого сервером, роблячи його інтерактивним у переглядачі. Гідраційна обробка коштує — для її виконання потрібно завантажити і виконати JavaScript. Фраза: “Злишкова гідрація сповільнювала час до інтерактивності — ми перетворили декілька компонентів на серверні компоненти.”

** Потік SSR ** Відтворення з боку сервера, яке надсилає HTML до переглядача по частинах, замість очікування на готовність повної сторінки. Обмеження припинення керують тим, які частини потоку буде передано першими. Фраза: “З потоковою SSR, оболонка сторінки прибуває за мілісекунди, а розділи з великим обсягом даних надходять по мережі, коли вони розв’ язуються.”

Розміри пристрою Компонент React ( <Suspense fallback={<Loading />}> ), який визначає, що показувати під час завантаження даних або коду дочірнього компонента. У RSC, межі Suspense також визначають потокові шматки. Фраза: * “Огорнути панель рекомендацій рамкою Suspense, щоб вона не блокувала відтворення решти сторінки.” *

** РСК полезный груз ** Серіалізований опис дерева компонентів, відтвореного сервером, надісланого з сервера до клієнта. Клієнт використовує корисну інформацію RSC для узгодження дерева компонентів без перезавантаження всієї сторінки під час навігації. Фраза: “Вантаж RSC для цього маршруту занадто великий — ви надсилаєте занадто багато даних, які можуть бути відфільтровані на сервері.”

---

Отримання даних

** Отримання даних на сервері ** У RSC, компоненти можуть бути async функціями, що await дані безпосередньо — без useEffect, без завантаження станів в коді компонента, без викликів на стороні клієнта. Фраза: “Компоненти панелі управління є асинхронними компонентами сервера — вони отримують свої власні дані під час відтворення.”

** Дія сервера ** Асинхронна функція на стороні сервера, яку можна викликати з клієнта, зазвичай використовується для мутацій (звернення форм, запис бази даних). Дії сервера замінюють багато випадків використання маршрутів API. Фраза: “Ми замінили маршрут /api/update-profile на Server Action — менше коду, те ж обмеження безпеки.”

---

Про що треба знати про цю фразу

• “RSC переміщує межу отримання даних з клієнта на сервер, зменшуючи JavaScript, що надсилається до браузера.”
• “Ключовим компромісом є інтерактивність — компоненти сервера не можуть зберігати стан, тому інтерактивний інтерфейс користувача має бути компонентами клієнта.”
• “Відсутність витрат на гідрацію є причиною того, чому перетворення статичного інтерфейсу користувача на компоненти сервера покращує Core Web Vitals.”
• • “Розділи з обмеженнями дозволяють вам поступово відтворювати сторінку — спочатку критичний вміст, потім повільніші розділи, залежні від даних.” *

** Вправа: ** Візьміть сторінку маршрутизатора програм Next. js, яку ви створили, і напишіть пояснення архітектури у 100 слів щодо того, які компоненти є компонентами сервера і чому, використовуючи словник з цього повідомлення.

Розширення вашого розуміння: спільні комунікаційні виклики

Будьмо чесними – навіть досвідчені розробники іноді борються з швидкою еволюцією фронтендової термінології. Для людей, для яких англійська не є рідною мовою, навігація цими новими концепціями в React Server Components (RSCs) може бути особливо викликом. Це не тільки про розуміння чого вони означають; це також про те, як вони використовуються в розмовах і документації - конкретні фрази і очікування навколо них. Критичною частиною освоєння цього словника є розпізнавання тонких відмінностей у наголосі, рівнях формальності і нюансах, які можуть призвести до непорозумінь.

Одна з найчастіших проблем виникає під час перегляду коду. Уявіть, що ви отримали коментар на зразок: « Цей RSC повинен * повністю гідрувати * перед відтворенням інтерфейсу користувача. » Хоча це технічно правильно — стосовно процесу перенесення компонента, який спочатку було відтворено сервером, до його інтерактивного стану на клієнті — це може звучати вимогливо і, можливо, навіть обвинувачуючою. Конструктивнішою формулюванням може бути: « Давайте переконаємося, що цей RSC підготовлений для плавного переходу до інтерактивності на стороні клієнта; можливо, дослідження стратегій для оптимізації гідрації може поліпшити продуктивність ». Початковий коментар передбачає звинувачення; переглянутий фокусується на співпраці і поліпшенні. Аналогічно, повідомлення Slack, що обговорюють вибір архітектури, можуть швидко стати складними. « Нам потрібно реалізувати * потокове SSR *, щоб зменшити початкові часи завантаження », може бути неправильно інтерпретовано як технічна директива без пояснення, чому цей конкретний підхід є перевагою - можливо, він пов’ язаний з певною стратегією розгортання або профілем пристрою клієнта.

Іншою областю, де виникає плутанина, є розрізнення між « сервером » і « клієнтом ». Розробники часто використовують « сервер » випадково, але у контексті RSC, посилання на * компонент * як серверний компонент є більш точним. Опис PR у вигляді « Цей PR переробляє логіку отримання даних у компоненті сервера для поліпшення швидкодії » є більш зрозумілим, ніж просто сказати « цей PR покращує отримання даних ». Перший варіант негайно визначає обсяг і мету зміни. Це про комунікацію * де * робота відбувається, а не тільки * що * вона робить.

Нарешті, пам’ятайте, що технічний жаргон не завжди універсально розуміється. Завжди прагніть до ясності, пояснюючи свої аргументи - навіть якщо вам доведеться розбити складні концепції на простіші терміни. Не бійтеся задати прояснюючі питання; набагато краще шукати розуміння, ніж робити припущення.

# Example CLI command (using Vite) demonstrating a simple RSC setup:
npm create vite@latest my-rsc --template react-ts
cd my-rsc
npm install  # Installs dependencies