Next.js - przegląd w 1000 słów
Next.js jest jednym z wielu statycznych generatorów stron. Ale jedna cecha wyróżnia go na tle konkurencji. W tym krótkim przeglądzie postaram się ją opisać.
Zaktualizowano: 28 listopada 2023Mówi się, że “każdego dnia rodzi się nowy framework JavaScript”. Ta sentencja jest wyolbrzymiona i zabawna, ale jest w niej trochę prawdy. W szybko zmieniającym się świecie języka JavaScript, łatwo wziąć nowe, lśniące narzędzie i porzucić stare. Jednakże często okazuje się, że nowy framework nie jest najlepszy w przypadku naszego projektu. Mając to w pamięci, postanowiłem sobie, że nie wskoczę na żaden hype train. Ale nowe wydanie Next.js i prawie 100 000 gwiazdek na platformie GitHub sprawia, że hype train jest REALNY. Niemniej, zamiast ślepo wchodzić na pokład, postaram się zrobić krótki przegląd frameworka Next.js. I postaram się to zrobić w 1000 słów.
Next.js to framework oparty o React
Na początek rozwiejmy nieporozumienia, które zauważyłem przeglądając sieć. Next.js to nie jest alternatywa dla platform takich jak Vue, Angular czy React. To jest bardziej alternatywa dla statycznych generatorów stron takich jak Gatsby, Hugo czy Nuxt (to porównanie nie jest w 100% dokładne, ale dojedziemy do tego). Nie używasz React'a zamiast Next.js. Oczywiście możesz wybierać pomiędzy nimi, ale React'a używasz w obu przypadkach. Next buduje na fundamentach React'a. Dlatego możemy powiedzieć, że to jest framework2 lub meta-framework.
Jeżeli chcesz zobaczyć statyczne generatory treści w szerszym kontekście, wcześniej napisałem post o całej architekturze Jamstack.
Po co używać meta-frameworka?
“Po cholerę mi potrzebny meta-framework? Nie wystarczy mi sam React?”, możesz zapytać. I to zależy. To zależy od tego, co chcesz zbudować. Jeżeli potrzebujesz prostej aplikacji SPA (Single-Page Application), React prawdopodobnie wystarczy. Ale strony internetowe na produkcji potrzebują rozwiązania problemów z nawigacją, SEO, optymalizacją zdjęć, testowaniem i innych. React nie oferuje tego, a Next oferuje. Pomaga on rozwiązać te powszechnie występujące problemy. Na stronie głównej Next.js możemy przeczytać: “The React Framework for Production” i to zdanie zwięźle wyjaśnia czym on jest.
Strategie renderowania
Istnieje inny problem związany z aplikacjami SPA - client-side rendering (renderowanie po stronie klienta). Wrażenia z użytkowania, które oferują są podobne to natywnych aplikacji, co jest świetne, ale mają one swoje wady. Największymi dwoma są:
- Problemy z SEO. Serwer wysyłając taką aplikację serwuje pustą stronę i kod JavaScript, który buduje stronę po stronie klienta. Dlatego nie ma tam meta tagów takich jak title, description lub danych dla kart Twittera. Treści nie są konsekwentnie dostępne dla wyszukiwarek od Google, Twittera czy Facebooka. Googlebot potrafi odczytywać strony bazujące na JavaScript, ale nie powinieneś na tym polegać jeżeli indeksowanie jest dla ciebie priorytetem.
- Wolniejszy First Contentful Paint. FCP to jedna z metryk używana do mierzenia wydajności stron. Jest to czas potrzebny do wyświetlenia pierwszego elementu DOM. W przypadku tych aplikacji wysyłamy najpierw pustą stronę, dlatego wyniki zwykle są gorsze niż w przypadku renderowania po stronie serwera.
Server-Side Rendering (renderowanie po stronie serwera)
SSR nie jest nową strategią. Jeżeli rozpoznajesz PHP albo platformę .NET, to masz z nią doświadczenie. SSR w języku JavaScript działa podobnie, tylko z Node.js jako środowiskiem uruchomieniowym. Jak nazwa wskazuje to serwer jest odpowiedzialny za budowanie strony. Serwer generuje stronę w odpowiedzi na każde zapytanie. Eliminuje to wyżej wymienione problemy, ale tracimy funkcjonalności podobne do natywnych aplikacji. Nawigowanie pomiędzy stronami powoduje odświeżanie przeglądarki. Wrażenia z użytkowania są gorsze.
Static Site Generation (statyczne generowanie stron)
SSG przenosi proces renderowania z serwera do fazy budowania. Statyczny generator stron, taki jak Next, żąda listy wszystkich stron i renderuje je wraz z potrzebnymi plikami. Następnie te statyczne pliki możesz umieścić na Netlify lub innym CDN. Ta strategia łączy zalety poprzednich rozwiązań: zachowujemy interaktywność naszej aplikacji, a roboty indeksujące mają dostęp do treści. Zarówno maszyny jak i użytkownicy są zadowoleni. Ta strategia jest nawet szybsza niż renderowanie po stronie serwera, dzięki temu, że treści są renderowane wcześniej. “Ok, mamy tutaj zdecydowanego zwycięzcę. Czy możemy się rozejść?”. Nie tak szybko. Musimy pamiętać o tej fazie budowania. Może ona się wydłużyć w przypadku tysięcy stron, a dynamiczne dane nie mogą być po prostu wcześniej wygenerowane.
Strategie renderowania Next.js
Po co tak długo marudzić o strategiach renderowania we wpisie o Next.js? Bo myślę, że to jest główną zaletą Next.js. Teraz (konkretnie od wersji 9.3), Next oferuje je wszystkie. Istnieją różne funkcje do pobierania danych.
useSWR
Programiści stojący za Next.js stworzyli niestandardowy hak React do pobierania danych. Jest to rekomendowany sposób pobierania danych po stronie klienta.
Client-Side Rendering w Next.jsJSX
1import useSWR from 'swr'23const fetcher = (...args) => fetch(...args).then((res) => res.json())45function Profile() {6 const { data, error } = useSWR('/api/profile-data', fetcher)7}
getServerSideProps
Wyeksportowanie funkcji getServerSideProps
ze strony, pozwala renderować ją na każde zapytanie. Strona użyje danych zwróconych przez tę funkcję.
Server-Side Rendering w Next.jsJSX
1export async function getServerSideProps(context) {2 return {3 props: {}4 }5}
getStaticProps
Możesz wykorzystać generowanie statyczne z funkcją getStaticProps
. Next.js użyje zwróconych danych, aby renderować stronę w trakcie fazy budowania. Ta funkcja współpracuje z getStaticPaths
, aby dynamicznie generować ścieżki na podstawie dostarczonych treści.
Static Site Generation w Next.jsJSX
1export async function getStaticProps(context) {2 return {3 props: {}4 }5}
Incremental Static Regeneration (przyrostowe statyczne regenerowanie)
Ta strategia jest charakterystyczna dla Next.js. Próbuje niwelować problemy związane ze statyczną generacją. Pozwala ona na aktualizowanie stron, po fazie budowania aplikacji. W ten sposób nie musisz budować wszystkiego na nowo. Aby ją wykorzystać, musisz dodać parametr revalidate
do getStaticProps
.
Incremental Static Regeneration w Next.jsJSX
1export async function getStaticProps(context) {2 return {3 props: {},4 revalidate: 105 }6}
Najlepsze jest to, że możesz wybrać różne strategie renderowania dla różnych ścieżek. Część twojej strony może być statycznie wygenerowana, a reszta może być renderowana po stronie serwera. Jest to spora zaleta względem innych statycznych generatorów stron jak Gatsby, który koncentruje się tylko na statycznej generacji. Next.js jest bardziej uniwersalny i ma więcej zastosowań.
Inne funkcjonalności Next.js
Poza wieloma sposobami pobierania danych, Next.js oferuje rozwiązania dla problemów związanych z nawigacją (z wbudowanym modułem next/link
), przekierowaniami, optymalizacją zdjęć/fontów, dołączaniem meta tagów i innych skryptów. W domyśle wspiera Typescript, a także wiele sposobów stylowania (CSS modules, CSS-in-JS) i testowania (Jest, Cypress). Istnieje także Next CLI, które pomaga w zarządzaniu aplikacją. Ten wpis miał być krótkim przeglądem i zbliżam się do 1000 słów, dlatego tu zakończę. Jednakże ten framework zainteresował mnie i być może się go nauczę. Wydaje mi się, że przesiadka z jednego statycznego generatora stron na inny, nie powinna być trudna. Być może dodam bardziej szczegółowe wpisy na temat jego konkretnych funkcjonalności.
Next.js 13 wprowadził app router. Poza zmianą do nowej strategi rutowania, nowa wersja wprowadziła więcej zmian, takich jak server components. Mój post odnosił się do poprzedniego rutera - pages. Jednakże wszystkie informacje zawarte w tym poście są nadal aktualne. Nadal możesz korzystać z rutera pages. Strategie renderowania się nie zmieniły, ale implementacje mogą się różnić. Więcej detali znajdziesz w dokumentacji Next.js.