Next - React z SSR-em (Server-side renderingiem)

Strony i routing

Gdy pisaliśmy aplikacje SPA (single page application) w czystym Reactcie, do zmiany widoku potrzebowaliśmy zewnętrznej biblioteki. Jedną z najpopularniejszych jest react-router, która udostępnia nam swoje API w postaci komponentów takich jak np. BrowserRouter, Routes, Route czy Link - z ich wykorzystaniem możemy zbudować nasz routing. Poniżej przykład:

W next.js nie ma potrzeby korzystania z zewnętrznych paczek - dlatego, że ma wbudowany system routingu, który jest tworzony na podstawie file-systemu dokładniej struktury wewnątrz folderu /pages. Poniżej przedstawiam przykładową strukturę:

Teraz wystarczy, że przejdziemy pod ścieżkę /nazwa_pliku np. /about, aby wyświetlić daną stronę. Tak to wszystko, nie potrzebujemy wykorzystywać dziesięciu innych komponentów, żeby zmiana widoków w pełni działała.

Na zdjęciu powyżej możesz zauważyć dwie niejasne rzeczy. Pierwszą z nich jest plik o nazwie [slug].js. Jest to page z dynamiczną ścieżką, która musi być poprawnie wygenerowana, ale o tym dalej we wpisie. Drugą jest folder api, w którym definiujemy routy , do których możemy wykonywać zapytania http.

Pre-render

Next.js ma wbudowane dwie formy prerenderowania stron. Pierwszym jest static generation, a drugim server-side rendering. Każda z tych form ma swoje funkcje do pobierania danych, są to: getStaticProps, getStaticPaths oraz getServerSideProps. Pierwsze dwie są wykonywane podczas budowania aplikacji (static generation), a ostatnia za każdym requestem tzn. za każdym razem, gdy wejdziemy na jakąś stronę naszej aplikacji (server-side rendering -> ssr).

GetStaticProps

Pozwala nam wykonać różne akcje w trakcie budowania np. zapytanie http, a potem pobrane dane zwrócić w obiekcie props, który zostanie przekazany do page’a. Inna przydatną rzeczą, która może zostać zwrócona, jest revalidate, pozwala to na zaktualizowanie wygenerowanej strony bez potrzeby przebudowy aplikacji. Revalidate przyjmuje liczbę sekund, co ile strona powinna zostać przebudowana, oprócz tego, co każde zapytanie spowoduje przebudowę. GetStaticProps może też zwrócić: obiekt notFound oraz redirect.

GetStaticPaths

Gdy page korzysta z dynamicznego routingu getStaticPaths, pozwala wygenerować określone ścieżki podczas budowania. Weźmy na przykład przypadek, gdy mamy jakiś headless cms z naszymi artykułami blogowymi i chcemy dla nich wygenerować ścieżki, pod którymi będą dostępne konkretne wpisy. W getStaticPaths powinniśmy je pobrać i zmapować poniżej przykład implementacji:

Możemy to połączyć z getStaticProps, żeby pobrać dany wpis:

Dzięki implementacji obu funkcji mamy poprawnie wygenerowane ścieżki oraz dla każdego, w tym przypadku, wpisu pobrane dane z CMS-a, które możemy wyświetlić w sposób, jaki potrzebujemy.

GetServerSideProps

Działa bardzo podobnie do getStaticProps - z tym, że wykonywana jest za każdym razem, gdy wejdziemy na stronę.

API

W folderze pages/api definiujemy routy, pod które możemy wykonywać zapytania http. Działają one praktycznie tak samo, jak te które znamy z node.js. Stwórzmy sobie plik w folderze api/:

Teraz, jak wykonamy zapytanie GET pod ścieżkę /api/posts, zostanie wykonany kod z bloku if’a z linijki 4, możemy tam odpytać bazę danych o wszystkie posty lub statyczne dane.

Inne

Zdjęcia

Mamy dostępny komponent Image, który optymalizuje ładowanie zdjęć za nas. Co się za tym kryje?

• ładowanie zdjęć dopiero, wtedy gdy są w obrębie viewportu,
• ładowanie poprawnych wielkości zdjęć w zależności od urządzenia,
• ustawienie priorytetu ładowanych zdjęć,
• opcjonalny blur, gdy zdjęcie nie zostało jeszcze załadowane.

Webpack

Jeżeli chcemy nadpisać, zmodyfikować lub cokolwiek innego zrobić z konfiguracją webpacka, wystarczy nadpisać ją w pliku next.config. To tyle, nie musimy ejectować projektu, tak jak to się robiło w czystym Reactcie.

AMP

Bez problemu możemy stworzyć stronę w wersji AMP-owej. Wystarczy dodać:

Amp: true oznacza, że strona będzie posiadać tylko wersje AMP-ową, a hybrid, że również zwykłą wersję.

Podsumowanie

Next.js to framework, o którym przed długi czas nie zapomnimy. To, co opisałem powyżej, to tylko zalążek jego możliwości i mała zachęta, aby przetestować to rozwiązanie na własną rękę. Warto tutaj wspomnieć, że ludzie odpowiedzialni za Next są we współpracy z core teamem Reacta, co z pewnością zaowocuje w kolejnych wersjach.