Kurs Angular Material – cz.2 struktura aplikacji

Witam, oto druga część kursu Angular 4 Material. Dziś zajmiemy się i zgłębimy strukturę aplikacji, opisze po kolei z jakich plików składa się nasza aplikacja. Opisze po któtce ich funkcjonalności a w następnym poście przejdziemy do opisu plików „src” czyli źródła naszego programu

Zaczynamy…

1. Kaltalog e2e

Tutaj znajdują sie testy funkcjonalne, ale na razie nie będziemy z nich korzystać.

2. node_modules i package.json

W ostatnim poście mówiłem o bardzo ważnym narzędziu jakim jest NPM(node package manager ). To dzięki niemu pobieramy i instalujemy ważne biblioteki czy komponenty naszej aplikacji. Z NPM wiąże się folder node_modules który zawiera wszystkie niezbędne moduły, biblioteki i skrypty,  które będą potrzebne w tworzeniu naszego kodu. Node zawsze wie o istnieniu katalogu node_modules i pozwala na korzystanie z zawartych w nim modułów w każdym projekcie. To oznacza, że każdy moduł jest jakby wbudowany w projekt i możemy z niego korzystać. Zwykle jednak katalog ten osiąga monstrualne rozmiary niczym czarna dziura i ciężko jest go wrzucić do jakiegokolwiek repozytorium.

Nie jest zatem dobrą praktyką by wrzucać ten katalog do naszego repo. Dlatego też z pomocą przychodzi nam plik package.json

Jest to plik konfiguracyjny który mówi Node.js jakie pliki należy pobrać. Jeżeli będziemy w katalogu gdzie będzie plik package.json i wpiszemy polecenie:

npm install

lub krócej:

npm i

To Node poszuka pliku package.json,  stworzy katalog node_modules i ściągnie do niego wszystkie rzeczy które mamy w naszym pliku. Dzięki temu w repozytorium taki plik opisuje nam konfigurację aplikacji i przekazuje co NPM musi pobrać aby zbudować aplikację. Zatem nie potrzebujemy wielkiego node_modules, tylko kiedy pobierzemy nasze repozytorium i uruchomimy polecenie

[sourcecode language=”plain”] npm install [/sourcecode]

pobrane zostaną wszystkie zależności i biblioteki.

Plick package.json przechowuje także referencje do wykonywanych skryptów. Jeżeli popatrzymy sobie na nasz plik:

{
  "name": "food-calc",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "^7.0.4",
    "@angular/cdk": "^7.2.2",
    "@angular/common": "~7.0.0",
    "@angular/compiler": "~7.0.0",
    "@angular/core": "~7.0.0",
    "@angular/forms": "~7.0.0",
    "@angular/http": "~7.0.0",
    "@angular/material": "^7.2.2",
    "@angular/platform-browser": "~7.0.0",
    "@angular/platform-browser-dynamic": "~7.0.0",
    "@angular/router": "~7.0.0",
    "core-js": "^2.5.4",
    "rxjs": "~6.3.3",
    "zone.js": "~0.8.26"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "~0.10.0",
    "@angular/cli": "~7.0.6",
    "@angular/compiler-cli": "~7.0.0",
    "@angular/language-service": "~7.0.0",
    "@types/node": "~8.9.4",
    "@types/jasmine": "~2.8.8",
    "@types/jasminewd2": "~2.0.3",
    "codelyzer": "~4.5.0",
    "jasmine-core": "~2.99.1",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~3.0.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-coverage-istanbul-reporter": "~2.0.1",
    "karma-jasmine": "~1.1.2",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.4.0",
    "ts-node": "~7.0.0",
    "tslint": "~5.11.0",
    "typescript": "~3.1.6"
  }
}

to zauważymy istnienie wartości: „scripts”. Dalej w „scripts” widzimy,  że jest takie coś jak: start, build, test. Jest to referencja do wykonania odpowiednich skryptów przez webpacka, a w zasadzie naszego narzędzia angular CLI. Zatem kiedy wpiszemy:

npm start

ng serve

import { AppModule } from './app/app.module';

5. polyfills.json

Plik w którym załączamy polifile do obsługi starszych przeglądarek. Załączone tak są także biblioteki które uzupełniają różne zależności np:

import 'core-js/es6/reflect';
import 'core-js/es7/reflect';
import 'zone.js/dist/zone';

"emitDecoratorMetadata": true,
"experimentalDecorators": true,

15. tslint.json

Jest to plik konfiguracyjny który mówi narzędziu TSLint, jak sprawdzać kod języka TypeScript w przypadku czytelności, obsługi i błędów funkcjonalności. Jest powszechnie wspierany przez nowoczesne systemy redaktorów i kompilatorów i może być dostosowany do własnych reguł, konfiguracji i formatów. Czyli będzie on  odpowiedzialny za pokazanie nam ewentualnych błędów składniowych, które możemy popełnić pisząc kod

I chyba wszystko:) Wiedza ta da nam ogólny wgląd w strukturę aplikacji a także, wiedzę gdzie możemy coś zmienić by pisanie stało się łatwiejsze. Wiedza ta jest elementarna i warto poświecić czas na dokładniejsze zbadanie jej.

W następnej lekcji będę omawiał główny moduł Angulara oraz jego komponent.

Serdecznie zapraszam do komentowania.