React Server Components: Еволюція - javascript.org.ua

Вступ

Коли я починав свій шлях як розробник програмного забезпечення близько десяти років тому, я просто писав HTML, CSS, JavaScript і кілька скриптів на Python 2; тоді ми повністю покладалися на PHP і SQL для серверної комунікації з клієнтом. Пізніше наступним кроком стало магічне слово "React", яке означало реакцію на зміни через стани або ефекти. Це моє розуміння, без поглибленого аналізу, з чуток, що один інженер з Facebook створив цю технологію; це був вибух у тому, як ми почали писати фронтенд-частину.

З розвитком програмної розробки і ускладненням бекенд-систем, компоненти серверного рендерингу в React (RSC) стали необхідними для еволюції нашої екосистеми. Це нагадує мені часи, коли величезні JavaScript-бандли та «loading» спіннери були всюди. Давайте розглянемо, як RSC змінює гру.

Революція в продуктивності

Основна зміна, яку приносить RSC, не тільки технічна, але й філософська. Замість того, щоб відправляти цілі дерева компонентів на клієнт, RSC дозволяє рендерити компоненти на сервері, зберігаючи ту інтерактивність, яку ми любимо в React. Я міг переносити панелі управління на RSC, і це досить просто, нічого надзвичайного, але очевидний вплив на панелі управління був значним — розмір зменшився на 60%.

Ось реальний приклад, з яким я зіткнувся нещодавно:

// До: Компонент клієнта  
 import { ComplexDataGrid } from 'heavy-grid-library';  
import { format } from 'date-fns';  

export default function Dashboard() {  
 const [data, setData] = useState([]);  

 useEffect(() => {  
 fetchDashboardData().then(setData);  
 }, []);  

 return ;  
}

У цьому традиційному клієнтському підході відбуваються кілька речей:

Ми імпортуємо важку бібліотеку для роботи з даними, яка упаковується разом із нашим JavaScript для клієнта.
Ми використовуємо useState для керування даними локально в браузері.
Дані завантажуються після монтування компонента за допомогою useEffect.
Користувач бачить стан завантаження, поки дані отримуються.
Усі обчислення даних відбуваються на стороні клієнта, що може уповільнити пристрій користувача.

Тепер подивимося на версію з RSC:

import { sql } from '@vercel/postgres';  
import { DataGrid } from './DataGrid';  

export default async function Dashboard() {  
 const data = await sql`SELECT * FROM dashboard_metrics`;  

 return ;  
}

Компонент за замовчуванням є асинхронним — більше не потрібно використовувати useEffect або useState.
Прямий доступ до бази даних через серверні запити.
Не потрібно писати код для отримання даних на стороні клієнта.
Відсутність стану завантаження для початкових даних.
Обробка даних відбувається на потужних серверах, а не на пристрої користувача.
Імпортований компонент DataGrid може бути значно легшим, оскільки він лише обробляє відображення, а не отримання даних.

Трансформація вражає. Більше не потрібно використовувати useEffect, більше не треба отримувати дані на стороні клієнта, і, що найголовніше, більше не потрібно відправляти зайвий JavaScript на клієнт.

Реальні переваги

Вплив RSC не обмежується лише показниками продуктивності. Працюючи з RSC, я помітив, що запити до бази даних тепер відбуваються ближче до джерела даних (у наведеному вище прикладі це не найкраща практика), компоненти стали простішими та більш зосередженими, патерни аутентифікації та авторизації стали прямолінійними, а SEO поліпшення практично з’являються самі по собі, що раніше не відбувалося у світі React.

Однак найбільша перевага — це досвід розробника. Писати компоненти, які можуть безпосередньо отримувати доступ до вашої бази даних (безпечно!) — це як суперсила. Це наче мати найкраще з обох світів: компонентну архітектуру від React з перевагами продуктивності серверного рендерингу, як найсучасніший з Next.js.

Торги

Будьмо чесними: RSC не є ідеальним.
Т mental model (ментальна модель) вимагає часу для засвоєння, особливо коли йдеться про розуміння межі між клієнтом і сервером; для мене це певного роду складна операція в чорній коробці. Я слідую прикладу міграції, і ми зіткнулися з деякими труднощами через сторонні бібліотеки, які не були сумісні з RSC. Рішення? Гібридний підхід:

'use client';  
// Компонент клієнта для інтерактивності  
export function SearchFilter({ onSearch }) {  
 return  onSearch(e.target.value)} />;  
}  

// Компонент сервера для отримання даних  
export default async function ProductList() {  
 const products = await getProducts();  
 return (  
 <>  



 );  
}

Давайте розберемо, що відбувається в цьому гібридному підході:

Директива use client чітко позначає компонент SearchFilter як клієнтський.
SearchFilter обробляє взаємодії користувача (події onChange), що можуть відбуватися лише на клієнті.
ProductList залишається серверним компонентом, який отримує дані на сервері.
Компонентна композиція дозволяє нам поєднувати рендеринг на сервері та клієнті там, де це доречно.
Лише інтерактивні частини (SearchFilter) переносять JavaScript на клієнт.
Частини, що містять багато даних (ProductGrid з продуктами), рендеряться на сервері.

Висновок (Майбутнє — серверно-орієнтоване)

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

Для команд, що розробляють додатки з великим обсягом даних, RSC пропонує шлях до кращої продуктивності без шкоди для досвіду розробника. Оскільки середовище розвивається і більше бібліотек стають сумісними з RSC, я очікую, що цей підхід стане стандартним способом створення React додатків.

Поділіться своїм досвідом

Чи почали ви використовувати React Server Components у своїх проектах? Буду радий почути від вас, які труднощі та досягнення ви отримали, в коментарях нижче.
Поставте ❤️, якщо ця стаття допомогла вам краще зрозуміти RSC, і не забудьте підписатися, щоб отримувати більше глибоких статей про сучасні системи.

Про автора

Іван Дуарт — бекенд-розробник з досвідом роботи на фрілансі. Він захоплюється веб-розробкою та штучним інтелектом і любить ділитися своїми знаннями через туторіали та статті. Слідуйте за мною в X, Github і LinkedIn для більше інсайтів та оновлень.

📬 Підпишіться на нашу розсилку

Читайте статті від ByteUp безпосередньо у вашій поштовій скриньці.

Підпишіться на розсилку і не пропустіть нові матеріали.

Оригінально опубліковано на https://dev.to 7 січня 2025 року.

Перекладено з: React Server Components: The Evolution