Nowoczesny React: Konfiguracja serwera na produkcji - architektura SPA
od Podstaw
5 godz. 59 min · ReactJS · Full-stack i Programowanie
Michał JabłońskiCzego się nauczysz
- Podstawy React jako biblioteki UI
- Konfiguracja środowiska programistycznego
- Składnia i reguły JSX
- Komponenty React jako podstawowe bloki aplikacji
- Przekazywanie danych przez props
- Renderowanie list i kolekcji
- Renderowanie warunkowe elementów
- Stylowanie komponentów i moduły CSS
- Zarządzanie stanem aplikacji
- Hook useState do przechowywania danych
- Hook useEffect do efektów ubocznych
- Routing i nawigacja w aplikacji SPA
- Parametry dynamiczne w adresach URL
- Obsługa formularzy i walidacja danych
- Integracja z biblioteką Formik
- Komunikacja z API backendowym
- Obsługa operacji asynchronicznych
- Zarządzanie stanem ładowania i błędów
- Narzędzia deweloperskie do debugowania
- Konfiguracja środowiska produkcyjnego
- Deploy aplikacji na platformie hostingowej
Nowoczesny React
React przeszedł długą ścieżkę rozwoju i część z jego funkcjonalności nie są już powszechnie używane. Dlatego w tym kursie skupimy się na najnowszych technikach pracy z biblioteką - poznasz współczesne podejście do budowania komponentów z wykorzystaniem hooks (useState, useEffect), zrozumiesz zasady kompozycji i zarządzania stanem aplikacji. Pokażemy Ci też jak efektywnie korzystać z narzędzi deweloperskich, debugować kod i wdrażać aplikacje na produkcję z użyciem współczesnych platform jak Vercel.
Hooki
Hooki to fundament nowoczesnego Reacta, który całkowicie zmienił sposób tworzenia komponentów. W kursie nauczysz się efektywnie zarządzać stanem aplikacji używając useState, wykorzystywać useEffect do operacji lifecycle i side-effects, oraz poznasz reguły korzystania z hooków. Wszystko to przećwiczysz w praktycznych zadaniach, takich jak implementacja filtrowania listy elementów, gdzie zastosujesz zdobytą wiedzę w realnym scenariuszu.
Formularze
Obsługa formularzy to nieodłączny element każdej aplikacji webowej. Pokażemy Ci jak kontrolować wartości pól input, wykorzystać popularną bibliotekę Formik do zarządzania złożonymi formularzami oraz implementować walidację danych. Wiedza ta zostanie utrwalona poprzez praktyczne zadanie, w którym rozwiniesz formularz o dodatkowe pola i zastosujesz poznane techniki w rzeczywistym przypadku użycia.
Połączenie z back-endem
Większość aplikacji wymaga komunikacji z serwerem. Nauczysz się jak poprawnie wykonywać operacje asynchroniczne w komponentach React, obsługiwać stany ładowania i błędów, oraz efektywnie korzystać z klienta HTTP do zapytań AJAX. Zaczniesz od pracy z przygotowanym mockiem API, by następnie przejść do prawdziwej integracji z back-endem. W praktycznym zadaniu zaimplementujesz pełny przepływ danych - od pobrania, przez wyświetlenie, aż po wysłanie na serwer.
Deployment
Poza budową aplikacji React, w kursie znajdziesz także moduł poświęcony wdrażaniu aplikacji na produkcję. Poznasz prawidłową konfigurację serwera produkcyjnego dla architektury SPA, nauczysz się zarządzać zmiennymi środowiskowymi poprzez pliki .env oraz przeprowadzisz deployment na platformie Vercel. Dzięki temu Twoja aplikacja będzie nie tylko działać lokalnie, ale także będzie gotowa do użycia przez realnych użytkowników w internecie.
Dla kogo jest ten kurs?
Nowoczesny React stworzyliśmy z myślą o osobach, które chcą nauczyć się Reacta i jednocześnie znają JavaScript. Niezależnie od tego, czy React jest Twoim pierwszym frameworkiem, czy masz już doświadczenie w pracy np. ze Svelte czy Vue, ten materiał jest dla Ciebie. Wskazane jest również posiadanie ogólnej wiedzy na temat tworzenia interfejsów z HTML i CSS oraz obsługi narzędzi takich jak Git czy podstawy pracy z terminalem.
W tym module skupimy się na deployment aplikacji oraz o możliwych problemach,
które możesz napotkać w momencie, w którym chcemy wystawić swoją stronę
na tak zwaną produkcję.
Skupmy się na katalogu Dist.
To będzie centrum naszych zainteresowań, bo to tutaj mamy zbudowaną aplikację.
Spróbuj sobie jeszcze raz, na wszelki wypadek wybudować najbardziej aktualną
wersję tej aplikacji i niepotrzebne nam są pozostałe elementy.
Pozostałe taski, które tutaj mogłyby być, czyli takie jak dev, takie jak backend.
Na razie chcemy to pominąć.
Pokażę Ci to na przykładzie wystawienia pewnego serwera web i posłuży mi do
tego package, który nazywa się Search.
Chcemy wystawić ten materiał, który tutaj przygotowałem na tą lekcję.
Jest to standard http://serwer.
Chodzi o standardowy sposób działania serwera.
Zobacz mam tu index html i tu jest jakiś wycinek widoku.
I teraz ten index może nas rotować do Exchange.
Czyli to jest ten folder i index się nam uruchomi do ad person.
I to jest ten folder i ten indeks HTML się uruchomi albo not exist.
No to nie mamy nic, więc liczymy na jakiś error 404.
Na dobry początek spróbujmy sobie zainstalować komendą npm
install, ale z flagą G serwa.
To posłuży nam do tego, żebyśmy mogli wystawić ten serwer, żebyś zobaczył
standardową zasadę działania właśnie serwera HTTP.
Czyli w momencie gdy puszczę teraz komendę serwer i tutaj standard http://server
zobaczysz, że na porcie 3000 osadzi mi się właśnie ten zespół plików,
który tutaj sobie przygotowałem.
Chodzi konkretnie o ten index HTML.
Od niego sobie zacznijmy. Zobaczmy.
Mamy people home page i tutaj możemy zobaczyć jak to teraz działa.
Zauważ, że jeżeli dam exchange to to przechodzi na Exchange.
Mamy Exchange party page Add person, mamy add person i 404 examples.
No to mamy The request it could not be found.
To jest informacja oczywiście z serwera.
Surf nie odnalazł tej ścieżki, ale dlaczego jej nie odnalazł?
Jak to się dzieje, że odnajduje te pozostałe ścieżki?
Standardowy sposób działania serwerów WEP jest taki, że jeżeli rotujemy do katalogu,
czyli tak jak tutaj na przykład Exchange, to server szuka czy w tym
Exchange będzie index HTML.
Jeśli tak to zaserwuje nam ten index HTML.
Więc tutaj mamy Exchange party page i zobacz w tym indeksie jest
dokładnie Exchange party page.
Jest to is success, dlatego jest na zielono i mamy tutaj is active zaznaczone
na tym nav bar item I to jest standardowa statyczna strona.
Czyli te statyczne strony tutaj są połączone razem, więc mamy tutaj routing.
Widzimy, że ten routing działa.
Działa dlatego, że mamy te foldery i podfoldery i w ten sposób jak gdyby na
dowolnym serwerze, w którym wrzucilibyśmy właśnie ten mój przygotowany katalog, tak
by to dokładnie działało, czyli People działa, Exchange działa, ad person działa.
No ale 404 example nie będzie nigdzie działało.
Tak będzie funkcjonował ten serwer.
Teraz przeszkadza mi jedna rzecz i będę ją sobie chciał zmodyfikować.
Narzędzie serw działa jako tzw.
CLI i w tym momencie to co nam przeszkadza to ten port 3000.
Dlatego, że chcielibyśmy osadzić go sobie na innym porcie i okazuje się, że da się
to zrobić, ponieważ to narzędzie Skellige ma pewne możliwości, takie jak Surf
Help i tutaj mamy je wylistowane.
I tutaj na przykład możemy sobie określić port, na którym chcemy nasłuchiwać.
I uwaga, będziemy też poruszać to zagadnienie, czyli rewrite all
not found request to index HTML.
Zanim to jednak zobaczymy, zobaczmy sobie inny port, ponieważ chciałbym sobie
wystawić swoją aplikację, ale mieć też dostępny backend.
Czyli spróbujmy sobie ustalić backend i tutaj na porcie 3000.
Teraz ten port będzie zajęty dlatego, że chcę mieć tam backend, a tutaj zrobię
sobie surf i chciałbym wystawić sobie Disa, czyli naszą aplikację.
Ale uwaga teraz będzie to lista.
Czyli tutaj jest wybudowana przez nas aplikacja to komendą build i tego dist
chciałbym sobie wystawić, żeby zobaczyć jak to będzie działało.
I uwaga teraz mamy Surf DST i listen będzie na porcie 5000.
Mamy port 5000.
Zobaczmy sobie jak działa nasza aplikacja, jeśli sobie tutaj wejdziemy.
Widzimy, że aplikacja działa.
Ładuje się poprawnie dlatego, że na porcie 3000 jest osadzony nasz backend.
Jeżeli nie masz włączonego backendu, albo nie zmienisz portu tego właśnie serwa,
którego mamy tutaj, no to on sam do siebie będzie się odwoływał, czyli na localhost
3000, co sprawi, że tutaj będziemy mieli błędy dlatego, że nie będziemy w
stanie załadować poprawnie danych.
Zwróćmy jednak uwagę, że wszystko działa.
Gdybyśmy tutaj przeszli sobie teraz do Exchange Exchange, działa poprawnie.
PeoplePeople działa poprawnie, bo to jest ta główna strona, A person też mamy
oczywiście, czyli nasz routing i widzimy, że nie odświeża się strona, w
przeciwieństwie do tego co mieliśmy tutaj na tym porcie.
3000.
Teraz już ten serwer nie pracuje na tym porcie, ale gdybyśmy tu przeklikiwali
zauważysz, że ta strona się odświeżała.
Natomiast tutaj nie mamy odświeżenia strony.
Wygląda, że wszystko działa poprawnie, jednak nic bardziej mylnego.
Jak mawia klasyk.
Dlatego, że jeżeli odświeżymy sobie tą stronę, okaże się, że strona próbuje
zacząć od Exchange, czyli dosłownie ten list, który został tutaj
wystawiony jako serwer.
Mamy tutaj HTML, więc React nam się osadził na stronie i steruje tą stroną.
I tak długo jak zaczniemy od strony głównej wszystko będzie w porządku.
Dlatego, że tutaj routing przejmuje kontrolę nad tymi podstronami,
nie wypuszcza nas nigdzie dalej.
Mamy preventDefault.
Natomiast jeśli zaczniemy nasz pierwszy request, gdzie odświeżymy sobie stronę na
przykład od Exchange, to tak jakbyśmy spodziewali się, że w środku Dist
będzie właśnie katalog Exchange.
No i tu jest problem.
Tu jest problem dlatego, że nasza architektura to tzw.
single page application, czyli my nie mamy żadnych podstron i my nie chcemy mieć
natywnego zachowania serwera takie, jakie miało miejsce tutaj.
Dlatego, że nie mamy żadnych folderów i podstron robionych w ten sposób.
Cała nasza aplikacja jest rysowana tutaj w tym divie root i cała sterowana jest
przez Reacta całą naszą aplikację.
Właśnie w tej architekturze Single Page Application mamy właśnie w tym miejscu i
router React router dom będzie sterował naszymi widokami i je rysował.
Nie chcemy poza to wychodzić.
Jak sobie to naprawić?
Okazuje się, że każdy serwer, który wystawiamy, każdy serwer
web możemy skonfigurować.
Zwróć uwagę, że tutaj jeżeli znamy tego właśnie serwera iHelp dostaniemy
informację, że możemy robić tak zwany fallback do indexHTML.
Dlatego to się nazywa właśnie single page application.
Bo mamy tylko single page, czyli indexhtml i dlatego ta architektura stąd ma swoją
nazwę właśnie single page application, ponieważ chcemy przelutować wszystkie
ścieżki właśnie do index HTML, jeśli nie będą poprawne.
W takim układzie zobaczmy sobie jeszcze raz.
Spróbujmy wystawić katalog list.
Upewnij się, że jesteś na właściwej ścieżce projektu, czyli Secret Viewer.
U mnie mam tutaj katalog list, ale teraz zrobimy to wystawiając
to na localhost 5000.
Zrobimy to jako S, czyli w tej architekturze SPA.
I tutaj wystawimy katalog DiST.
Zobaczmy jak to teraz działa.
Teraz, jeżeli zacznę od Exchange.
Wszystko działa poprawnie dlatego, że mamy coś takiego jak Get Exchange,
ale tutaj jest już return 200.
Dlatego, że mamy ten fallback do indeksu i zobacz, że
jeżeli mamy folback na index HTML, to ten index HTML i React router dom może się
uruchomić i będzie wiedział jak ma wyświetlić Exchange.
W ten sposób oszukujemy troszeczkę serwer, który nam wystawia to,
że ma takie podfoldery.
To nie jest prawda.
Takich podfolderów nie ma, ale ten serwer sam wie, że jeżeli czegoś nie ma to
ma nas odprowadzić do index HTML.
I tak samo poradzisz sobie na produkcji.
Tutaj oczywiście mamy toola, który jest klejem i ten serwer ma taką specjalną
konfigurację, którą wystawiamy po prostu z flagą S.
Jeżeli sobie puścimy komendę help, dostaniemy tą flagę S i
tak możemy sobie poradzić.
Tego serwa możesz traktować jako taki Twój tool do wystawiania lokalnie serwera, do
sprawdzenia jak działa produkcja, czy produkcja działa poprawnie.
No i jeżeli mamy coś w architekturze SPA musimy zrobić.
S Czyli tą flagę musimy sobie tutaj dodać, żeby to nam zadziałało, żeby to się
zaczęło przepisywać na index HTML jako fallback.
Natomiast jeśli chodzi o pozostałe serwery dla przykładu Apache też ma tak zwany
rewrite rules, które trzeba zastosować jeżeli mamy architekturę SPA.
Więc jeżeli robisz to na własną rękę i chcesz na Apaczu wystawić sobie właśnie
tego DSa, to wszystkie elementy z DSa wrzucasz na Apacza, a dodatkowo dla tego
konkretnego katalogu robisz taki rewrite engine on i takie rewrite conditions.
Jeżeli masz engine X i na engine X robisz właśnie SPA i chcesz wystawić te pliki,
musisz zrobić coś takiego jak w files.
I teraz to jest taki feedback, że jeżeli coś nie istnieje na serwerze, czyli jeżeli
próbujemy jakąś ścieżkę i tej ścieżki po prostu nie ma, czyli nie jest to ani plik,
ani nie jest to folder z index HTML w środku, no to wtedy jak gdyby wszystko
idzie do tego głównego index HTML.
I w ten oto sposób możemy sobie przygotować w pełni działającą
aplikację na produkcję.
Jest jeszcze jeden problem związany z tym, że oczywiście tutaj uderzamy do
backendu, który stoi lokalnie.
Czyli zwróć uwagę, że to jest local host 3000.
Nie do końca chcielibyśmy, żeby produkcyjnie to był localhost 3000.
Jeśli chcemy mieć jakieś API, jeśli chcemy je wystawić to ma być API produkcyjne, to
trzeba by podmienić w jakiś sposób to, co się tutaj znajduje i o tym
będzie następna lekcja.