Szkolenie z Express - część 2: Tworzenie szkieletu aplikacji webowej

Trwa tłumaczenie tego artykułu.

W drugim artykule cyklu Szkolenie z Express zbudujemy "szkielet" aplikacji webowej, którą będziemy później rozbudowywać o kolejne elementy: ścieżki, szablony/widoki i odwołania do bazy danych. 

Wymagania: Przeczytanie artykułu Set up a Node development environment.
Cele: Umiejętność samodzielnego utworzenia własnego projektu aplikacji webowej za pomocą Express Application Generator.

Wstęp

Artykuł przedstawia tworzenie szkieletu aplikacji webowej Biblioteka przy pomocy narzędzia Express Application Generator. W kolejnych artukułach będziemy ją rozbudowywać o kolejne elementy. Proces tworzenia jest bardzo prosty i wymaga wywołania tylko jednego polecenia z nazwą budowanej aplikacji. Opcjonalnie można także podać silnik do renderowania widoków i generator CSS.

W kolejnych sekcjach przyjrzymy się bliżej działaniu generatora, poznamy opcje widoków/CSS. Zostanie też wyjaścniona struktura utworzonej aplikacji. Na zakończenie poznasz metody uruchomienia utworzonej aplikacji oraz zweryfikowania jej działania. 

Uwaga: Express Application Generator nie jest jedynym narzędziem do tworzenia aplikacji Express, a struktura utworzonych projektów nie jest jedyną właściwą. Wygenerowana aplikacji posiada modularną strukturę, która może być łatwo rozszerzana oraz jest wystarczająco przejrzysta i zrozumiała.  Informacje o tym jak zrobić minimalną aplikację Express znajdziesz w Hello world example (dokumentacja Express).

Uwaga: W tym szkoleniu wykorzystano wersję Express zdefiniowaną w pliku package.json utworzonym automatycznie przez Express Application Generator. I niekoniecznie jest to najnowsza wersja! 

Korzystanie z generatora aplikacji

Powinieneś mieć zainstalowany generator jako część środowiska przygotowanego w artykule Przygotowanie środowiska programisty Node. W ramach przypomnienia instalacja generatora aplikacji Express wymaga wpisania poniższego polecenia:

npm install express-generator -g

Generator posiada wiele opcji, które możesz poznać za pomocą polecenia --help (lub -h):

> express --help

    Usage: express [options] [dir]


  Options:

        --version        output the version number
    -e, --ejs            add ejs engine support
        --pug            add pug engine support
        --hbs            add handlebars engine support
    -H, --hogan          add hogan.js engine support
    -v, --view <engine>  add view <engine> support (dust|ejs|hbs|hjs|jade|pug|twig|vash) (defaults to jade)
        --no-view        use static html instead of view engine
    -c, --css <engine>   add stylesheet <engine> support (less|stylus|compass|sass) (defaults to plain css)
        --git            add .gitignore
    -f, --force          force on non-empty directory
    -h, --help           output usage information

Wpisując wyłącznie polecenie express utworzysz projekt w bieżącym katalogu z domyślnym silnikiem zablonów Jade i czystym CSS. Dodanie nazwy katalogu spowoduje utworzenie projektu w tym właśnie katalogu.     

express

Opcją --view możesz wyspecyfikować inny generator widoków a --css podać preprocesor CSS.

Uwaga:  Pozostałe opcje wyboru silnika szablonów(n.p. --hogan, --ejs, --hbs itd.) są już przestarzałe i nie należy z nich korzystać . Skorzystaj z opcji --view (or -v)!

Jaki silnik szablonów wykorzystać?

Paczka Express Application Generator pozwala na skonfigurowanie wielu popularnych silników renderujących, w tym EJS, Hbs, Pug (Jade), Twig i Vash, spośród których to Jade jest domyślnie instalowany w sytuacji braku specyfikacji silnika. Sam Express wspiera znaczną liczbę innych języków szablonów out of the box.

Uwaga: Jeśli chcesz skorzystać z silnika, który nie jest wspierany przez generator to zapoznaj się publikacją Using template engines with Express (dokumentacja Express) i dokuemntacją wybranego silnika.

Ogólnie mówiąc powinnieneś wybrać taki silnik szablonów, który dostarcza wszystkich potrzebnych Ci funkcji i pozwala na szybkie osiągnięcie produktywności. Innymi słowy kieruj się tymi samymi regułami, którymi się kierujesz wybierając pozostałe komponenty. Podczas wyboru powinieneś rozważyć kilka kwestii:

  • czas osiągnięcia zadawalającej produktywności - jeśli Twój zespół posiada już jakieś doświadczenie w pracy z danym jezykiem szablonów to zapewne szybciej osiągnie sprawność w posługiwaniu się nim. Jeśli nie, to rozważ język łatwy do przyswojenia.    
  • popularność i aktywność - rozważ wybór silnika popularnego i posiadającego aktywną społeczność. Jest to ważne, bo pozwala mieć wsparcie doświadczonych użytkowników w problematycznych sytuacjach pojawiających się w trakcie cyklu życia aplikacji. 
  • styl - niektóre silniki szablonów korzystają ze speyficznych znaczników do oznaczania miejsc wypełnianych zawartością pośród "zwykłego" kodu HTML, a inne korzystają ze specyficznej składni (np. w postaci wcięć lub nazw bloków).
  • wydajność/ czas renderowania
  • funkcjonalność - warto uwzględnić podczas wyboru silnika także dostepność następujących funkcji:
    • Dziedziczenie layoutów: ten mechanizm pozwala zdefiniować szablon bazowy, który może zostać wykorzystany do budowy kolejnych poprzez przejęcie fragmentów bazowego i dodanie elementów specyficznych dla tworzonego szablonu. Jest to znacznie lepsze podejście od budowania szablonu na zasadzie dołączania wymaganych komponentów lub tworzenia za każdym razem od podstaw.    
    • Wsparcie dla dyrektywy typu "include": tego typu dyrektywa pozwala na umieszczanie w szablonie innych szablonów.
    • Możliwość definiowania zmiennych i wykonywania instrukcji ieracyjnych.
    • Zdolność formatowania wartości na poziomie szablonu (np. operacja typu upper-case, formatowanie daty).
    • Zdolność generowania dokumentów wyjściowych w innych formatach od HTML (np. JSON lub XML).
    • Obsługa operacji asynchronicznych i przesyłania strumieniowego.

Wskazówka:  W Intenecie znajduje się wiele zasobów, które mogą pomóc w porównaniu wiel opcji!

W naszym projekcie wykorzystamy generator szablonów Pug (poprzednio funkcjonował pod nazwą Jade), który jest najpopularniejszym narzędziem tego typu w środowisku Express/JavaScript i intalowanym wraz z generatorem aplikacji.

Jakiego preprocesora arkuszy stylów CSS należy użyć?

Express Application Generator pozwala na utworzenie projektu, który można skonfigurować do pracy z najbardziej znanymi preprocesorami stylów CSS: LESS, SASS, Compass, Stylus.

Uwaga: CSS  posiada pewne ograniczenia, które czynią definiowanie niektórych reguł bardzo trudnymi. Preprocesory dają możliwość wykorzystania bogatszej i o znacznie wiekszych możliwościach składni do definiowania reguł styli i kompilacji ich do tradycyjnego formatu CSS wykorzystywanego przez przeglądarki.

Podobnie jak przy wyborze silnika szablonów, tak i przy wyborze preprocesora powinieneś się kierować preferencjami zespołu, aby osiągnąć żądaną produktywność. W naszym projekcie wykorzystamy ustawienia domyślne, czyli tzw. vanilla CSS, ponieważ nie będziemy korzystać ze zbyt skomplikowanych reguł, a czysty CSS będzie dla nas wystarczająco dobry.

Jakiej bazy danych uzyć?

Wygenerowany kod aplikacji nie jest skonfigurowany do współpracy z bazą danych. Oczywiście aplikacje Express moga korzystać z  dowolnego silnika bazodanowego wspieranego przez środowisko Node (sam Express nie stawia żadnych specjalnych wymagań co do stosowanej bazy danych). Itegrację aplikacji z bazą danych omówimy w późniejszym artykule.

Tworzenie projektu

Stworzymy na początek przykładowy projekt pod nazwą express-locallibrary-tutorial korzystający z generatora szablonów Pug i czystego CSS.

Utwórz katalog projektu o podanej wyżej nazwie i przejdź do niego. Uruch teraz Express Application Generator wpisując w wierszu poleceń (terminalu) poniższą komendę:

express express-locallibrary-tutorial --view=pug

Generator aplikacji utworzy poniższą strukturę plików i katalogów.

   create : express-locallibrary-tutorial\
   create : express-locallibrary-tutorial\public\
   create : express-locallibrary-tutorial\public\javascripts\
   create : express-locallibrary-tutorial\public\images\
   create : express-locallibrary-tutorial\public\stylesheets\
   create : express-locallibrary-tutorial\public\stylesheets\style.css
   create : express-locallibrary-tutorial\routes\
   create : express-locallibrary-tutorial\routes\index.js
   create : express-locallibrary-tutorial\routes\users.js
   create : express-locallibrary-tutorial\views\
   create : express-locallibrary-tutorial\views\error.pug
   create : express-locallibrary-tutorial\views\index.pug
   create : express-locallibrary-tutorial\views\layout.pug
   create : express-locallibrary-tutorial\app.js
   create : express-locallibrary-tutorial\package.json
   create : express-locallibrary-tutorial\bin\
   create : express-locallibrary-tutorial\bin\www

   change directory:
     > cd express-locallibrary-tutorial

   install dependencies:
     > npm install

   run the app (Bash (Linux or macOS))
     > DEBUG=express-locallibrary-tutorial:* npm start

   run the app (PowerShell (Windows))
     > $ENV:DEBUG = "express-locallibrary-tutorial:*"; npm start

   run the app (Command Prompt (Windows)):
     > SET DEBUG=express-locallibrary-tutorial:* & npm start

Na końcu zwróconych przez generator komunikatów znajdują się instrukcje w jaki sposób zainstalować wymagane pakiety (ich spis znajduje się w pliku package.json) i jak uruchomić aplikację.

Uruchomienie szkieletu aplikacji

W katalogu mamy na razie kompletny szkielet naszego projektu, a nasza aplikacja nie wykonuje zbyt wielu zadań. Warto jednak uruchmić ją w tej początkowej postaci, aby sprawdzić czy działa.

  1. Na początku zainstaluj zależności(polecenie install pobierze wymienione w package.json pliki).
    cd express-locallibrary-tutorial
    npm install
  2. Uruchom aplikację.
    • W systemie Windows użyj tego polecenia:
      SET DEBUG=express-locallibrary-tutorial:* & npm start
    • W sytemach macOS lub Linux wpisz jak poniżej:
      DEBUG=express-locallibrary-tutorial:* npm start
      
  3. Wpisz w przeglądarce adres http://localhost:3000/ aby dostać się do strony aplikacji.

W przeglądarce powinieneś zobaczyć stronę podobą do tej poniżej:

Browser for default Express app generator website

Gratulacje! Twoja aplikacja Express działa i jest dostępna na Twojej lokalnej maszynie pod portem 3000.

Uwaga: Możesz też uruchomić aplikację korzystająć z polecenia npm start. Ustawiając zmienną DEBUG możesz włączyć wyświetlanie komunikatów logowania i debugowania. Przykładowo podczas odświeżenia powyższej strony aplikacji zobaczysz poniższe komunikaty w oknie konsoli:

>SET DEBUG=express-locallibrary-tutorial:* & npm start

> express-locallibrary-tutorial@0.0.0 start D:\github\mdn\test\exprgen\express-locallibrary-tutorial
> node ./bin/www

  express-locallibrary-tutorial:server Listening on port 3000 +0ms
GET / 304 490.296 ms - -
GET /stylesheets/style.css 200 4.886 ms - 111

Włączenie restartowania serwera po modyfikacji plików

Jakakolwiek zmiana w naszym projekcie nie będzie widoczna dopóki nie wykonasz ponownego uruchomienia serwera. Z czasem może to być bardzo irytujące, gdy każda zmiana będzie wymagała ciągłego zatrzymywania i ponownego uruchamiania serwera. Dlatego warto poświecić nieco czasu na zautomatyzowanie tej czynności.

Odpowiednim narzędziem do tego celu jest nodemon. Zwykle jest instalowany globalnie, ale tutaj zainstalujemy go lokalnie jako zależność developerską, aby każdy developer pracujący z aplikacją miał go po zainstalowaniu projektu. Wywołaj poniższe polecenia w głównym katalogu naszego projektu::

npm install --save-dev nodemon

Jeśli jednak chcesz zainstalować nodemon globalnie, a nie tylko w swoim projekcie dodając wpis do package.json, to wpisz taką wersję polecenia:  

npm install -g nodemon

Gdy otworzysz plik package.json swojego projektu to powinieneś zobaczyć nową sekcję z poniższą zależnością:

 "devDependencies": {
    "nodemon": "^2.0.4"
} 

Ponieważ nasze narzedzie nie została zainstalowane globalnie, to nie możemy go uruchomić wprost z linii poleceń (dopóki nie dodamy go do ścieżki). Możemy je jednak wywołać wprost ze skryptu NPM, bo NPM wie wszystko o zainstalowanych pakietach. Znajdź sekcję scripts w swoim pliku package.json. Dodaj do niej dwa wiersze ze skryptami "devstart" i "serverstart", Pamiętaj o dodaniu na końcu każdego wiersza (oprócz ostatniego) znaku przecinka:    

  "scripts": {
    "start": "node ./bin/www",
    "devstart": "nodemon ./bin/www",
    "serverstart": "DEBUG=express-locallibrary-tutorial:* npm run devstart"
  },

Możemy teraz uruchomić serwer w prawie taki sam sposób jak poprzednio, ale przy pomocy polecenia devstart

  • W systemie Windows wpisz polecenie w takiej postaci:
    SET DEBUG=express-locallibrary-tutorial:* & npm run devstart
  • W systemach macOS lub Linux użyj tej postaci:
    DEBUG=express-locallibrary-tutorial:* npm run devstart
    

Uwaga:  Od tej chwili każda zmiana jakiegokolwiek pliku projektu powoduje restart serwera (możesz też zrestartować serwer wpisując w dowolnym momencie polecenie rs w terminalu). Nadal jednak będziesz musiał odświeżać stronę w przeglądarce.

Od teraz musimy uruchamiać skrypty poleceniem "npm run <scriptname>" zamiast zwykłego npm start, ponieważ „start” jest w rzeczywistości poleceniem NPM, które jest odwzorowane na skrypt o takiej nazwie. Mogliśmy zamienić polecenie w skrypcie start, ale podczas programowania chcemy używać tylko nodemon, więc sensowne jest utworzenie nowego polecenia skryptu.

Dodanie polecenia serverstart w sekji skryptów pliku package.json jest dobrym rozwiązaniem, które pozwala uniknąć wpisywania długim poleceń uruchamiających serwer. Zwróć uwagę, że niektóre konkretne polecenia dodane do skryptu działają tylko w systemie macOS lub Linux.

Wygenerowany projekt

Przyjrzyjmy się bliżej projektowi, który stworzyliśmy.

Struktura katalogów

Utworzony projekt wraz z zainstalowanymi zależnościami ma przedstawioną poniżej strukturę (pliki są elementami z prefiksem "/").

Plik package.json definiuje spis wymaganych przez naszą aplikację pakietów oraz zawiera wiele innych informacji o aplikacji. W pliku tym są też zdefiniowane skrypty, w tym też skrypt startowy, który wywołuje punkt wejścia aplikacji, czyli plik JavaScript /bin/www. Skrypt ten po ustawieniu mechanizmu obslugi błędów uruchamia plik app.js, który wykonuje resztę pracy.

W katalogu /routes znajdują się moduły obsługujące ścieżki aplikacji. Szablony generowanych stron przechowywane są w katalogu /views.    

/express-locallibrary-tutorial
    app.js
    /bin
        www
    package.json
    package-lock.json
    /node_modules
        [about 6700 subdirectories and files]
    /public
        /images
        /javascripts
        /stylesheets
            style.css
    /routes
        index.js
        users.js
    /views
        error.pug
        index.pug
        layout.pug
  

W kolejnych sekcjach znajdziesz więcej szczegółów dotyczących plików projektu. 

package.json

Plik package.json:

{
  "name": "express-locallibrary-tutorial",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "start": "node ./bin/www"
  },
  "dependencies": {
    "cookie-parser": "~1.4.4",
    "debug": "~2.6.9",
    "express": "~4.16.1",
    "http-errors": "~1.6.3",
    "morgan": "~1.9.1",
    "pug": "2.0.0-beta11"
  },
  "devDependencies": {
    "nodemon": "^2.0.4"
  }
}

Sekcja zależności zawiera paczkę express i wybrany przez nas silnik szablonów (pug). Oprócz tego znajdują się w niej jeszcze inne paczki przydatne w aplikacjach webowych:

  • cookie-parser: służy do parsowania ciasteczek i zapewnia przeniesienie ich do req.cookies (zasadniczo daje możliwość wygodnego dostępu do informacji w nagłówkach cookie)
  • debug: niewielka paczka służąca do debugowania. której mechanizm jest wzorowany na technice wykorzystywanej w rdzeniu środowiska Node.
  • morgan: Narzędzie do rejestrowania zdarzeń (logger) w warstwie obsługi żądań HTTP.
  • http-errors: Tworzenie błędów HTTP w razie potrzeby (zgodnych z obsługa błędów w aplikacjach express).

W sekcji scripts zdefiniowany jest skrypt "start", który jest tym samym skryptem wywoływanym poleceniem npm start, gdy chcemy uruchomić serwer. Z definicji tego skryptu wynika, że uruchomia on plik ./bin/www z kodem JavaScript.  

  "scripts": {
    "start": "node ./bin/www",
    "devstart": "nodemon ./bin/www",
    "serverstart": "DEBUG=express-locallibrary-tutorial:* npm run devstart"
  },

Pozostałe skrypty devstart i serverstart  możemy wykorzystywać do uruchomienia tego samego pliku ./bin/www  ale z użyciem nodemon niż node (jak zostało to wyjaśnione w sekcji Włączenie restartowania serwera po modyfikacji plików).

Plik www

Plik /bin/www jest punktem wejścia aplikacji! Pierwszą rzeczą jaką wykonuje ten plik to funkcja require(), która kieruje do prawdziwego punktu zaczynającego wykonywanie aplikacji (app.js, w głównym katalogu projektu), w którym następuje przygotowanie i zwrócenie obiektu aplikacji  express().

#!/usr/bin/env node

/**
 * Module dependencies.
 */

var app = require('../app');

Uwaga: require() jest funkcją globalną środowiska Node, która importuje moduł do bieżącego pliku. W powyższym kodzie moduł app.js został podany z użyciem ścieżki względnej i z pominięciem opcjonalnego rozszerzenia .js.

Pozostała część kodu tego pliku konfiguruje serwer HTTP z aplikacją pracującą pod wskazanym portem (numer portu jest zdefiniowany w zmiennej środowiskowej lub przyjmowana jest wartość 3000 jeśli brak takiej zmiennej). W dalszej części następuje uruchomienie nasłuchiwania i raportowania błędów serwera i połączeń. Na razie nie musisz znać wszystkich szczegółów tego kodu (wszystko w tym pliku jest standardowym kodem), choć jeśli jesteś zainteresowany możesz go przejrzeć.

app.js

Ten plik jest odpowiedzialny za utworzenie obiektu aplikacji (pod konwencjonalną nazwą app), jej skonfigurowanie wraz z warstwami pośrednimi i wyeksportowanie jej z modułu. Kod poniżej zawiera tę cześć pliku app.js, która zawiera tworzenie i eksportowanie obiektu aplikacji:

var express = require('express');
var app = express();
...
module.exports = app;

Powrót do punktu wejściowego, czyli do pliku www,  następuje w linii  zawierającej  module.exports, która eksportuje obiekt app aplikacji i zwraca go do wywołującego kodu, który ten moduł zaimportował.

Czas teraz na szczegóły pliku app.js. Na początku importowne są dość użyteczne moduły przy pomocy funkcji require(), w tym http-errorsexpressmorgan i cookie-parser, które wcześniej zostały pobrane przez menadżera NPM, oraz pakiet path, który jest częścią środowiska Node i odpowiada za parsowanie ścieżek do plików i katalogów.  

var createError = require('http-errors');
var express = require('express');
var path = require('path');
var cookieParser = require('cookie-parser');
var logger = require('morgan');

Kolejne funkcje require(), importują moduły z katalogu routes. Zawierają one kody źródłowe obsługujące zbióry ścieżek naszej aplikacji (URL). Gdy będziemy rozbudowywać aplikację o kolejne ścieżki, na przykład zwracają listę wszystkich książek naszej biblioteki, to będziemy musieli dodać nowy plik z definicją operacji wykonywanych pod tą ścieżką.    

var indexRouter = require('./routes/index');
var usersRouter = require('./routes/users');

Uwaga: W tym miejscu tylko zaimportowaliśmy moduły, na razie nie korzystamy z tych ścieżek (nastapi to później). 

Następnie tworzymy obiekt app za pomocą zaimportowanego modułu express, po czym konfigurujemy go do pracy z wybranym silnikiem szablonów. W pierwszym kroku określa się lokalizację szablonów poprzez przypisanie katalogu do zmiennej 'views'. W drugim należy podać nazwę wykorzystywanej biblioteki szablonów (w naszym przypadku jest to "pug").   

var app = express();

// view engine setup
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'pug');

Następna sekcja zawiera szereg wywołań metody use na obiekcie aplikacji, których zadaniem jest dodanie bibliotek wykorzystywanych w warstwie pośredniej całego łańcucha przetwarzania żądań. Oprócz dołączonych wcześniej modułów zewnętrznych, wykorzystujemy także moduł express.static, którego zadaniem jest obsługa plików statycznych z katalogu /public naszego projektu. 

app.use(logger('dev'));
app.use(express.json());
app.use(express.urlencoded({ extended: false }));
app.use(cookieParser());
app.use(express.static(path.join(__dirname, 'public')));

Po skonfigurowaniu warstwy pośredniej możemy dodać (poprzednio już zaimportowane) nasze skrypty obsługujące żądania ścieżek. Zaimportowane pliki definiują poszczególne ścieżki dla różnych części naszej aplikacji:

app.use('/', indexRouter);
app.use('/users', usersRouter);

Uwaga: Podane powyżej ścieżki  ('/' i '/users') są traktowane jako przedrostki tras zdefiniowanych w importowanych plikach. Na przykład, jeśli zaimportowany moduł users definiuje ścieżkę względną /profile, to dostęp do tej ścieżki będzie możliwy pod /users/profile. Ścieżki zostaną dokładniej omówione w następnych artykułach.

Końcowym etapem konfigurowania warstwy pośredniej jest dodanie obsługi błędów i odpowiedzi HTTP 404.

// catch 404 and forward to error handler
app.use(function(req, res, next) {
  next(createError(404));
});

// error handler
app.use(function(err, req, res, next) {
  // set locals, only providing error in development
  res.locals.message = err.message;
  res.locals.error = req.app.get('env') === 'development' ? err : {};

  // render the error page
  res.status(err.status || 500);
  res.render('error');
});

Obiekt aplikacji Express jest teraz w pełni skonfigurowany. Ostatnim działaniem w skrypcie jest wyeksportowanie obiektu z bieżącego modułu (w ten sposób staje się on dostępny w pliku /bin/www po zaimportowaniu).

module.exports = app;

Ścieżki

Plik definiujący obsługę żądań kierowanych do ścieżki /routes/users.js znajduje się poniżej (struktura wszystkich plików ścieżek jest bardzo podobna, dlatego nie ma potrzeby oglądania pliku index). Na początku znajduje się znana już funkcja importująca moduł express, z którego pobierany jest obiekt express.Router . Po zdefiniowaniu obsługi żądania, obiekt rutera jest exportowany z modułu (dzięki czemu może być zaimportowany w app.js).    

var express = require('express');
var router = express.Router();

/* GET users listing. */
router.get('/', function(req, res, next) {
  res.send('respond with a resource');
});

module.exports = router;

Ruter definiuje metodę, która będzie wywoływana w chwily pojawienia się żądania GET protokołu HTTP skierowanego pod adres zgodny z wzorcem. Pełna ścieżka do tej metody zostanie zdefiniowana gdy moduł ('/users') zostanie zaimportowany i zostanie dodany przedrostek ('/') w module importujacym. Krótko mówiąc, ściezka zostanie użyta, gdy skierowane zostanie  żądanie z URL zawierającym /users/.  

Wskazówka: Wypróbuj działanie rutera uruchamiając serwer i odwiedzając w przeglądarce URL http://localhost:3000/users/. Powinieneś zobaczyć komunikat: 'respond with a resoure'. 

Interesującym elementem w kodzie metody obsługującej żądanie GET jest trzeci argument next, co świadczy o tym, że jest to metoda warstwy poredniej a nie prosta funkcja zwrotna. Chociaż na razie w metodzie nie korzystamy z tego argumentu to być może będzie potrzebny w przyszłości, gdy zechsze dodać wiecej metod obsługujących ścieżkę  '/'.

Widoki (szablony)

Widoki (szablony) są przechowywane w katalogu /views (tak jak zdefiniowano to w pliku app.js) i posiadają rozszerzenie .pug. Metoda Response.render() jest wykorzystywana do renderowania strony HTML na podstawie szablonu i dostarczonych do niego wartości zmiennych, po czym gotowy dokument jest wysyłany do jako odpowiedź żądania. W znajdującym się kodzie poniżej pochodzącym z pliku możesz obaczyć jak funkcja obsługi żądania ścieżki renderuje szablon "index" na podstawie przekazanej zmiennej "title".  

/* GET home page. */
router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express' });
});

Szablon "index" (index.pug) jest przedsatwiony poniżej. Składnię szablonów omówimy poźniej. To co na razie powinieneś wiedzieć to to, że zmienna title (zawierająca napisz 'Express') została wstawiona w określonym miejscu szablonu.

extends layout

block content
  h1= title
  p Welcome to #{title}

Challenge yourself

Create a new route in /routes/users.js that will display the text "You're so cool" at URL /users/cool/. Test it by running the server and visiting http://localhost:3000/users/cool/ in your browser

Summary

You have now created a skeleton website project for the Local Library and verified that it runs using node. Most importantly, you also understand how the project is structured, so you have a good idea where we need to make changes to add routes and views for our local library.

Next, we'll start modifying the skeleton so that it works as a library website.

See also

In this module