React Server Components: Przyszłość rozwoju React

by Ian Hernandez
React Server Components: Przyszłość rozwoju React thumbnail

React był potęgą w tworzeniu aplikacji internetowych przez ostatnie dziesięć lat.

Wszyscy widzieliśmy, jak ewoluowało to od nieporęcznych komponentów klasowych do elegancji haków.

Ale React Server Components (RSCs)?

Nikt chyba nie spodziewał się tak dramatycznej zmiany w działaniu React.

Więc, czym dokładnie są Komponenty Serwera React? Jak działają? I co robią inaczej, czego React już nie mógł zrobić?

Aby odpowiedzieć na wszystkie te pytania, szybko omówimy podstawy. Jeśli potrzebujesz przypomnienia, rzucić okiem na ten przewodnik jak nauczyć się Reacta jako początkujący.

W tym poście przeprowadzimy Cię przez powody, dla których potrzebowaliśmy komponentów serwerowych React, jak działają, oraz jakie są główne korzyści z RSCs.

Zacznijmy!

Czym są komponenty serwerowe React?

Diagram drzewa komponentów serwera React pokazuje hierarchię i miejsca, w których różne typy komponentów są renderowane w aplikacji.

Pomyśl o komponentach serwera React jako o nowym sposobie tworzenia aplikacji React. Zamiast działać w przeglądarce jak typowe komponenty React, RSC działają bezpośrednio na twoim serwerze.

„Myślę, że RSC mają być “komponentyzacją” backendu, czyli odpowiednikiem backendu tego, co SPA React zrobił dla frontendu. W teorii, mogłyby w dużym stopniu wyeliminować potrzebę stosowania takich technologii jak REST i GraphQL, prowadząc do znacznie ściślejszej integracji między serwerem a klientem, ponieważ komponent mógłby przejść przez cały stos.” — ExternalBison54 na Reddit

Skoro RSC wykonuje się bezpośrednio na serwerze, może on efektywnie korzystać z zasobów backend, takich jak bazy danych i APIs bez dodatkowej warstwy pobierania danych.

Słownik DreamHost

API

Interfejs Programowania Aplikacji (API) to zbiór funkcji umożliwiających aplikacjom dostęp do danych i interakcję z komponentami zewnętrznymi, pełniący rolę kuriera między klientem a serwerem.

Czytaj więcej

Ale dlaczego w ogóle potrzebowaliśmy RSC?

Aby odpowiedzieć na to pytanie, cofnijmy się nieco.

Tradycyjny React: Renderowanie po stronie klienta (CSR)

React zawsze był biblioteką interfejsu użytkownika po stronie klienta.

Podstawowa idea stojąca za Reactem polega na podzieleniu całego projektu na mniejsze, niezależne jednostki nazywane komponentami. Te komponenty mogą zarządzać własnymi prywatnymi danymi (stan) i przekazywać dane między sobą (właściwości).

Pomyśl o tych komponentach jak o funkcjach JavaScript, które są pobierane i uruchamiane bezpośrednio w przeglądarce użytkownika. Kiedy ktoś odwiedza Twoją aplikację, jego przeglądarka pobiera cały kod komponentu, a React wkracza, aby wszystko wyrenderować:

Schemat blokowy: Przepływ pracy renderowania po stronie klienta, od żądania użytkownika do załadowania strony, w tym odpowiedź serwera i przetwarzanie przez przeglądarkę.
  • Przeglądarka pobiera HTML, JavaScript, CSS oraz inne zasoby.
  • React analizuje HTML, ustawia nasłuchiwacze zdarzeń dla interakcji użytkownika i pobiera wymagane dane.
  • Strona internetowa przekształca się w w pełni funkcjonalną aplikację React na Twoich oczach, a wszystko odbywa się za pomocą Twojej przeglądarki i komputera.

Chociaż ta metoda działa, ma ona pewne wady:

  • Wolne czasy ładowania: Czasy ładowania mogą być wolne, szczególnie dla złożonych aplikacji z wieloma komponentami, ponieważ teraz użytkownik musi czekać, aż wszystko zostanie najpierw pobrane.
  • Szkodliwe dla optymalizacji pod kątem wyszukiwarek (SEO): Początkowy HTML jest często tylko szkieletem — wystarczającym do pobrania JavaScriptu, który następnie renderuje resztę kodu. To utrudnia wyszukiwarkom zrozumienie, o co chodzi na stronie.
  • Zwolnienie w miarę rośnięcia aplikacji: Przetwarzanie po stronie klienta w JavaScriptu może obciążać zasoby, prowadząc do gorszego doświadczenia użytkownika, szczególnie gdy dodajesz więcej funkcjonalności.

Otrzymuj treści bezpośrednio do swojej skrzynki odbiorczej

Zapisz się teraz, aby otrzymywać wszystkie najnowsze aktualizacje bezpośrednio do swojej skrzynki odbiorczej.

Następna Iteracja: Renderowanie Po Stronie Serwera (SSR)

Aby rozwiązać problemy spowodowane renderowaniem po stronie klienta, społeczność React przyjęła renderowanie po stronie serwera (SSR).

Za pomocą SSR, serwer zajmuje się renderowaniem kodu do HTML przed jego wysłaniem.

Cały ten wygenerowany HTML jest następnie przekazywany do twojej przeglądarki/mobilnej, gotowy do wyświetlenia — aplikacja nie musi być kompilowana podczas działania, jak by to miało miejsce bez SSR.

Oto jak działa SSR:

Diagram pokazujący, jak działa renderowanie po stronie serwera, z przeglądarką żądającą HTML od serwera i otrzymującą w pełni wyrenderowaną stronę.
  • Serwer renderuje początkowy HTML dla każdego żądania.
  • Klient otrzymuje w pełni uformowaną strukturę HTML, co pozwala na szybsze początkowe ładowanie strony.
  • Następnie klient pobiera React i kod aplikacji, proces nazywany „hydracją”, który czyni stronę interaktywną.

Struktura HTML renderowana na serwerze jeszcze nie posiada funkcjonalności. 

React dodaje nasłuchiwacze zdarzeń, konfiguruje zarządzanie stanem wewnętrznym oraz dodaje inne funkcjonalności do HTML po jego pobraniu na urządzenie. Ten proces dodawania “życia” do strony jest znany jako hydracja.

Dlaczego SSR działa tak dobrze?

  1. Szybsze czasy początkowego ładowania: Użytkownicy widzą zawartość niemal natychmiast, ponieważ przeglądarka otrzymuje w pełni uformowany HTML, eliminując czas potrzebny do załadowania i wykonania JavaScript.
  2. Poprawione SEO: Wyszukiwarki łatwo przeszukują i indeksują HTML renderowany po stronie serwera. Bezpośredni dostęp przekłada się na lepszą optymalizację pod kątem wyszukiwarek dla twojej aplikacji.
  3. Zwiększona wydajność na wolniejszych urządzeniach: SSR zmniejsza obciążenie urządzenia użytkownika. Serwer przejmuje pracę, czyniąc twoją aplikację bardziej dostępną i wydajną, nawet przy wolniejszych połączeniach.

SSR, jednakże spowodował szereg dodatkowych problemów, co wymagało jeszcze lepszego rozwiązania:

  • Wolny czas do interakcji (TTI): Renderowanie po stronie serwera i hydratacja opóźniają zdolność użytkownika do zobaczenia i interakcji z aplikacją, dopóki cały proces się nie zakończy.
  • Obciążenie serwera: Serwer musi wykonać więcej pracy, co dodatkowo spowalnia czasy odpowiedzi dla skomplikowanych aplikacji, zwłaszcza gdy jest wielu użytkowników jednocześnie.
  • Złożoność konfiguracji: Konfiguracja i utrzymanie mogą być bardziej skomplikowane, szczególnie dla dużych aplikacji.

W końcu komponenty serwerowe React

W grudniu 2020, zespół React wprowadził “Komponenty Serwera React o Rozmiarze Zero” czyli RSCs.

To zmieniło nie tylko nasze myślenie o tworzeniu aplikacji React, ale także sposób, w jaki aplikacje React działają w tle. RSC rozwiązały wiele problemów, które mieliśmy z CSR i SSR.

„Dzięki RSCs, React staje się w pełni serwerowym frameworkiem oraz w pełni klienckim frameworkiem, czego nigdy wcześniej nie mieliśmy. I to umożliwia znacznie bliższą integrację między kodem serwerowym a kodem klienckim, niż było to kiedykolwiek możliwe wcześniej.” — ExternalBison54 na Reddit

Spójrzmy teraz na korzyści, które RSC przynoszą:

1. Zero rozmiar pakietu

RSC są renderowane całkowicie na serwerze, eliminując potrzebę wysyłania kodu JavaScript do klienta. To skutkuje:

  • Znacząco mniejsze rozmiary paczek JavaScript.
  • Szybsze ładowanie stron, szczególnie na wolniejszych sieciach.
  • Poprawiona wydajność na mniej potężnych urządzeniach.

W przeciwieństwie do SSR, gdzie całe drzewo komponentów React jest wysyłane do klienta w celu hydratacji, RSC pozostawiają kod tylko dla serwera na serwerze. To prowadzi do znacznie mniejszych pakietów po stronie klienta, o których mówiliśmy, czyniąc twoje aplikacje lżejszymi i bardziej responsywnymi.

2. Bezpośredni dostęp do backendu

RSC mogą bezpośrednio współdziałać z bazami danych i systemami plików bez potrzeby korzystania z warstwy API.

Jak widzisz w poniższym kodzie, zmienna kursy jest pobierana bezpośrednio z bazy danych, a interfejs użytkownika wyświetla listę course.id i course.name z kursy.map:

async function CourseList() {
  const db = await connectToDatabase();
  const courses = await db.query('SELECT * FROM courses');

  return (
    <ul>
      {courses.map(course => (
        <li key={course.id}>{course.name}</li>
      ))}
    </ul>
  );
}

To jest prostsze w porównaniu do tradycyjnego SSR, gdzie musiałbyś ustawić oddzielne trasy API do pobierania poszczególnych elementów danych.

3. Automatyczne dzielenie kodu

Z RSC otrzymujesz również bardziej szczegółowe dzielenie kodu i lepszą organizację kodu.

React przechowuje kod tylko dla serwera na serwerze i zapewnia, że nigdy nie zostanie przesłany do klienta. Komponenty klienta są automatycznie identyfikowane i wysyłane do klienta w celu hydratacji.

A cały pakiet staje się niezwykle zoptymalizowany, ponieważ klient otrzymuje dokładnie to, co jest potrzebne do w pełni funkcjonalnej aplikacji.

Z drugiej strony, SSR wymaga starannego ręcznego dzielenia kodu, aby zoptymalizować wydajność dla każdej dodatkowej strony.

4. Zmniejszony Efekt Wodospadu i Renderowanie Strumieniowe

Komponenty serwerowe React łączą renderowanie strumieniowe i równoległe pobieranie danych. To potężne połączenie znacznie redukuje “efekt wodospadu”, często obserwowany w tradycyjnym renderowaniu po stronie serwera.

Efekt Wodospadu

Efekt “wodospadu” spowalnia rozwój stron internetowych. Zasadniczo zmusza operacje do następowania po sobie, jakby wodospad przepływał przez serię skał.

Każdy krok musi poczekać, aż poprzedni się zakończy. To “czekanie” jest szczególnie zauważalne podczas pobierania danych. Jedno wywołanie API musi zostać zakończone, zanim rozpocznie się następne, co spowalnia czas ładowania strony.

Tabela z zakładki Sieć w Chrome pokazuje efekt wodospadu przy zapytaniach sieciowych, prezentując różne wywołania API i ich czas.

Renderowanie Strumieniowe

Renderowanie strumieniowe oferuje rozwiązanie. Zamiast czekać, aż cała strona zostanie wyrenderowana na serwerze, serwer może wysyłać fragmenty interfejsu użytkownika do klienta, jak tylko będą gotowe.

Diagram pokazuje renderowanie serwera strumieniowego: żądania sieciowe i osi czasu wykonania JavaScript, w tym znaczniki FCP i TTI.

Komponenty serwerowe React sprawiają, że renderowanie i pobieranie danych przebiega znacznie płynniej. Tworzy wiele komponentów serwerowych, które działają równolegle, unikając efektu kaskadowego.

Serwer zaczyna wysyłać HTML do klienta w momencie, gdy jakikolwiek element interfejsu użytkownika jest gotowy.

Więc w porównaniu do renderowania po stronie serwera, RSC:

  • Zezwól każdemu komponentowi na niezależne i równoległe pobieranie danych.
  • Serwer może przesyłać strumieniowo komponent, jak tylko jego dane będą gotowe, nie czekając na nadrobienie zaległości przez inne komponenty.
  • Użytkownicy widzą ładowanie się treści jedna po drugiej, co poprawia ich postrzeganie wydajności.

5. Płynna interakcja z komponentami klienta

Teraz, używanie RSC niekoniecznie oznacza, że musisz rezygnować z komponentów po stronie klienta. 

Oba komponenty mogą współistnieć i pomóc Ci stworzyć świetne ogólne doświadczenie aplikacji.

Pomyśl o aplikacji e-commerce. Przy SSR, cała aplikacja musi być renderowana po stronie serwera.

W RSC jednak możesz wybrać, które komponenty mają być renderowane po stronie serwera, a które po stronie klienta.

Na przykład, możesz użyć komponentów serwera do pobierania danych produktu i renderowania początkowej strony z listą produktów.

Następnie, komponenty klienta mogą obsługiwać interakcje użytkownika takie jak dodawanie przedmiotów do koszyka na zakupy lub zarządzanie recenzjami produktów.

Czy powinieneś dodać implementację RSC do swojego planu?

Nasz werdykt? RSCs dodają dużo wartości do rozwoju React.

Rozwiązują niektóre z najważniejszych problemów związanych z podejściami SSR i CSR: wydajność, pobieranie danych oraz doświadczenie dewelopera. Dla deweloperów, którzy dopiero zaczynają programować, ułatwiło to życie.

Czy teraz powinieneś dodać implementację RSC do swojego planu? Musimy odpowiedzieć tym przerażającym — to zależy.

Twoja aplikacja może działać zupełnie dobrze bez RSCs. I w tym przypadku, dodanie kolejnej warstwy abstrakcji może niewiele zmienić. Jednakże, jeśli planujesz skalowanie i myślisz, że RSCs mogą poprawić doświadczenie użytkownika w twojej aplikacji, spróbuj wprowadzić małe zmiany i skaluj od tego miejsca.

A jeśli potrzebujesz potężnego serwera do testowania RSC, uruchom DreamHost VPS.

DreamHost oferuje w pełni zarządzaną usługę VPS, gdzie możesz uruchamiać nawet najbardziej wymagające aplikacje bez obaw o utrzymanie serwera.

VPS Hosting
Hosting VPS

Wiemy, że masz wiele opcji VPS

Oto, jak oferta VPS DreamHost wyróżnia się na tle innych: wsparcie klienta 24/7, intuicyjny panel, skalowalna RAM, nieograniczona przepustowość, nieograniczona liczba domen hostingowych i przechowywanie SSD.

Zmień swój plan VPS