Spis pojęć i zagadnień, które po ukończeniu tego kursu powinni Państwo znać, oraz odnośniki do materiałów je omawiających. Niniejszy spis będzie uzupełniany w trakcie semestru.
HyperText Markup Language (HTML)
Cascading Style Sheets (CSS)
Hypertext Transfer Protocol (HTTP)
RFC 1738: Uniform Resource Locators (dostępne online).
Pozwala się przekonać, że URL-e zaczynające się od „http” i „https” nie są
jedynymi możliwymi. Obok HTTP istnieje wiele innych protokołów i usług, dla
których zdefiniowano ich własne schematy
RFC 1866: Hypertext Markup Language 2.0 (dostępne online).
Specyfikacja opisująca HTML w wersji używanej w pierwszej połowie lat 90. Warte przejrzenia są rozdział 5, zawierający listę znaczników używanych do wskazywania ról pełnionych przez poszczególne fragmenty tekstu, oraz rozdział 8, który omawia znaczniki służące do tworzenia interaktywnych formularzy.
Proszę nie opierać się na tej specyfikacji podczas tworzenia nowych dokumentów HTML. Część zdefiniowanych w niej znaczników jest przestarzała.
MDN: HTML elements reference (dostępne online).
Lista wszystkich rozpoznawanych przez współczesne przeglądarki znaczników z podstronami szczegółowo je opisującymi. W opisach są przykłady zastosowania, lista atrybutów, które mogą być użyte z danym znacznikiem, oraz — na samym końcu podstrony — tabelka informująca, od których wersji przeglądarki zaczęły rozpoznawać ten znacznik.
Cascading Style Sheets, level 1 (dostępne online).
Specyfikacja pierwszej wersji CSS z 1996 roku, na tyle jeszcze krótka, że opublikowano ją jako pojedynczą stronę. Można ją przejrzeć, aby zapoznać się z ideami leżącymi u podstaw CSS: pudełkowym modelem wizualnego formatowania dokumentu, własnościami kontrolującymi wygląd pudełek i tekstu w nich zawartego, selektorami pozwalającymi wskazywać te elementy HTML-owego dokumentu, których wygląd pragniemy zmodyfikować.
MDN: CSS reference (dostępne online).
Katalog rozpoznawanych przez współczesne przeglądarki własności i selektorów, a także innych rzeczy używanych podczas tworzenia arkuszy stylów. Na stronach ze szczegółowymi opisami są tabelki z minimalnymi wymaganymi wersjami przeglądarek.
MDN: Hypertext Transfer Protocol (dostępne online).
Przewodniki omawiające różne aspekty i zastosowania HTTP. Proszę najpierw przeczytać „Overview of HTTP”, potem „Using HTTP cookies”, „Cross-Origin Resource Sharing” i „HTTP authentication” (zwracając uwagę tylko na metody Basic i Bearer). Te cztery powinny wystarczyć na potrzeby pisania projektów zaliczeniowych.
Osoby chcące poszerzyć swą wiedzę mogą przejrzeć pozostałe przewodniki oraz RFC 9100, formalnie definiujący pojęcia używane w HTTP.
JavaScript jako język programowania
Środowisko przeglądarki internetowej
Środowisko linii komend (serwerowe)
MDN: JavaScript guides (dostępne online tutaj i tutaj).
Kursy programowania w języku JavaScript. Pomimo tego, że są częścią witryny Mozilla Developer Network i są skupione na pisaniu kodu wykonującego się w środowisku przeglądarki, to poruszają również temat pisania programów działających w serwerowym środowisku Node.js.
MDN: JavaScript reference (dostępne online) oraz Web APIs reference (dostępne online).
Specyfikacja samego języka oraz specyfikacje wbudowanych we współczesne przeglądarki bibliotek. Dwie najważniejsze to DOM, czyli Document Object Model, i rozszerzająca ją HTML DOM. Warto też zwrócić uwagę na Fetch API.
DOM określa postać drzewiastych struktur danych powstających w wyniku parsowania tekstowych dokumentów ze znacznikami. Mogą to być dokumenty HTML, ale również SVG, XML i inne. Węzłami drzew są obiekty; ich metody pozwalają na dostęp do atrybutów znacznika, elementów potomnych itd. Są też metody do modyfikowania modelu dokumentu oraz podłączania do jego elementów procedur obsługi zdarzeń.
HTML DOM definiuje specjalizowane klasy odpowiadające poszczególnym
znacznikom HTML. Na przykład, jeśli parser trafia w źródle strony na znacznik
<video>, to zamiast węzła klasy Element tworzy
węzeł klasy HTMLVideoElement. HTMLVideoElement
dziedziczy po Element i rozszerza ją m.in. o metody pozwalające
uruchomić i zatrzymać odtwarzanie filmu.
Fetch API stawia do dyspozycji programisty funkcję fetch(). Za
jej pomocą można w asynchroniczny sposób pobierać zasoby z serwerów HTTP.
dokumentacja interpretera Node.js (dostępna online).
Na samej górze strony głównej są odnośniki „Learn” i „Docs”. Pierwszy prowadzi do poradnika omawiającego różne aspekty tworzenia programów mających działać w środowisku Node.js — proszę w rozdziale „Getting Started” przeczytać wszystko aż do sekcji o menedżerze pakietów npm włącznie. Drugi odnośnik otwiera dokumentację programisty — w niej warto rzucić okiem na „Usage and example” oraz „HTTP”.
dokumentacja szkieletu Express (dostępna online).
W belce menu umieszczonej na górze stron witryny są podmenu „Getting started” i „Guide”. Warto po kolei przejrzeć ich zawartość. Następnym podmenu jest „API reference”, tu wystarczy zajrzeć do „5.x”. Specyfikacja API jest na tyle prosta i krótka, że należy ją w całości przeczytać.
Opis modelu dojrzałości Richardsona (dostępny online).
Krótkie wprowadzenie do tzw. Richardson Maturity Model. Oddawane projekty zaliczeniowe powinny być na poziomie 2. Proszę nie implementować poziomu 3, to dużo dodatkowej pracy, z której nie będzie zysku. Poziom 3 przydaje się w systemach eksploatowanych przez wiele lat i często modyfikowanych.
Dokumentacja API usługi Discogs (dostępna online).
Do przejrzenia jako przykład dobrze opracowanej dokumentacji, omawiającej obszerne REST API z mechanizmami autentykacji i limitowania liczby zapytań na sekundę. Szczególnie uważnie proszę przeczytać stronę wyświetlaną po kliknięciu nagłówka „Database” w panelu ze spisem treści. Omawia ona endpointy pozwalające na dostęp do informacji o zespołach muzycznych i wydanych przez nie płytach. Znajdujące się na niej przyciski z nazwą „Toggle” rozwijają przykłady możliwych odpowiedzi serwera.
Artykuły „What Is a REST API? Examples, Uses, and Challenges”, „How to create a REST API with Node.js and Express” i „REST API Best Practices: A Developer’s Guide to Building Reliable APIs”.
Autorami są członkowie zespołu rozwijającego platformę Postman z narzędziami wspomagającymi tworzenie usług sieciowych. Można przyjąć, że wiedzą co piszą.
Best practices for RESTful web API design (dostępne online).
Proszę czytać wybiórczo, część z zaleceń odnosi się do zaawansowanych kwestii i nie będzie Państwu potrzebna przy pisaniu projektu zaliczeniowego. W szczególności proszę zignorować zalecenia dotyczące poziomu 3 RMM (HATEOAS, dodawanie hiperlinków w odpowiedziach).
Aplikacja jest zbiorem plików JS, HTML, CSS itd., opublikowanym na witrynie i stamtąd pobieranym przez przeglądarkę. Współczesne podejście zakłada, że pliki źródłowe, z którymi pracuje twórca aplikacji, nie są bezpośrednio publikowane. Aby powstała „skompilowana”, czyli dystrybucyjna wersja aplikacji muszą one zostać przetworzone odpowiednimi narzędziami.
Zagadnienia ogólne
Biblioteka React
React służy tylko do tworzenia GUI aplikacji. Nie przyda się przy implementowaniu innych części kodu, takich jak:
integracja z serwerami REST przechowującymi dane
Samo wysyłanie zapytań HTTP pobierających / zapisujących dane jest łatwe. Skomplikowana jest integracja tego kodu z resztą aplikacji. Trzeba myśleć o obsłudze błędów, regularnym odświeżaniu danych na wypadek gdyby na serwerze się zmieniły, obsłudze kolizji jeśli aplikacja pozwala na edycję danych przez wielu użytkowników równocześnie, itp. Biblioteki takie jak TanStack Query czy SWR próbują w tym pomóc.
routing po stronie klienta
GUI aplikacji często podzielone jest na wiele widoków czy też ekranów. Np. sklep ma ekran główny, listy produktów z poszczególnych kategorii, szczegółowe informacje o produktach, koszyk itd. Takie GUI można zaimplementować definiując odrębne komponenty dla każdego typu ekranu i pamiętając w globalnym stanie aplikacji, co w danej chwili ma być widoczne, np. ProductDetails z prodId=XYZ123. Akcje użytkownika mogą powodować zmianę tego globalnego stanu i przejście na inny ekran.
Takie podejście znane jest jako SPA (ang. single-page application) i odpowiada sposobowi działania tradycyjnych aplikacji desktopowych. Przełączanie pomiędzy widokami nie wymaga komunikowania się z serwerem w celu pobrania kodu nowego ekranu (ściągane są co najwyżej nowe dane, które będą wyświetlone wewnątrz komponentu), aplikacja działa więc płynnie. Z punktu widzenia przeglądarki cały czas wyświetlana jest jedna i ta sama strona; to, że jej treść jest co chwilę modyfikowana z poziomu JavaScriptu nie ma dla przeglądarki znaczenia.
SPA jest jednak aplikacją webową, a nie desktopową, i uruchamia się ją otwierając odpowiedni URL. Oprócz URL-a reprezentującego aplikację jako całość i otwierającego jej główny ekran przeważnie chcemy mieć również URL-e odpowiadające ekranom podrzędnym, np. https://example.org/sklep.html#ProductDetails/XYZ123. Aby to zapewnić kod aplikacji musi, po pierwsze, w momencie uruchamiania aplikacji wyświetlać ekran wskazany sufiksem użytego URL-a i, po drugie, uaktualniać URL wyświetlany w belce adresowej przeglądarki gdy użytkownik przechodzi na nowy ekran.
Jest to tzw. routing, zwany też trasowaniem. Przykładowe biblioteki: React Router, TanStack Router.
Zamiast indywidualnie dobieranych bibliotek można użyć szkieletu aplikacyjnego (ang. framework), takiego jak np. Next.js. Na 99% będzie on miał mechanizmy obsługi routingu oraz REST-owych źródeł danych, a także mnóstwa innych rzeczy (co może niepotrzebnie skomplikować Państwa projekt).
MDN: Client-side tooling overview (dostępne online).
Przegląd rodzajów narzędzi wykorzystywanych przy tworzeniu javascriptowych aplikacji.
Dokumentacja programu Parcel (dostępna online).
Jeden z wielu programów do budowania aplikacji. Jego dokumentacja bardzo czytelnie opisuje sposób przetwarzania różnych rodzajów plików źródłowych. Parcel obsługuje m.in. szablony Pug, pliki HTML oraz pliki JavaScript i JSX. Inne programy tego typu mogą przetwarzać pliki trochę inaczej, ale ogólna idea będzie taka sama.
Dokumentacja biblioteki React (dostępna online).
Z przewodnika dla nowych użytkowników zalecam uważne przeczytanie strony „Thinking in React”. W części „Learn React” proszę przestudiować rozdziały „Describing the UI”, „Adding Interactivity” i „Managing State” (m.in. przedstawiony jest w nim zaczep useReducer, odradzam korzystanie z niego w projektach zaliczeniowych). Rozdział „Escape Hatches” można przejrzeć bardziej pobieżnie, ale proszę zwrócić uwagę na opis zaczepu useEffect.
Dokumentacja frameworka Next.js (dostępna online).
Zachęcam do zapoznania się z dwoma kursami będącymi częścią dokumentacji, „React Foundations” i „Next.js Foundations”. Są względnie krótkie i zilustrowane dobrze omówionymi przykładami kodu aplikacji. Pozwolą się Państwu zorientować jak szkielet aplikacyjny, taki jak Next.js, ma się do leżącej u jego podstaw biblioteki React.