Wiem, że poniekąd jest to odwrócenie kolejności. Piszę o generowaniu projektu Angularowego, a nie było jeszcze nic nt. nauki samego Angulara v4. Jak to?
Otóż w kolejnych wpisach chciałabym już bazować na realnym projekcie. Tłumaczyć Angular v4, rozwijając równocześnie naszą aplikację przykładową. Ale żeby to zrobić – potrzebujemy samej aplikacji. Stąd ta kolejność.
Co znajdziesz w artykule?
- Angular CLI – czyli co?
- Instalacja
- Generowanie projektu z wykorzystaniem Angular CLI
- Uruchomienie
- Struktura wygenerowanego projektu
Poziom: średniozaawansowany
Wymagania wstępne:
- Znajomość linii komend.
- Zainstalowany Node JS, umiejętność instalowania paczek (NPM).
Praca domowa:
- Wygeneruj swój pierwszy projekt z wykorzystaniem Angular CLI.
- Zrozum strukturę projektu Angularowego, gdzie czego szukać. Im lepiej będziesz się tam poruszać, tym lepiej dla Ciebie.
- Uruchom swój pierwszy projekt Angularowy (ng serve).
Wszystkie informacje jak to zrobić, znajdziesz w artykule. W razie problemów -śmiało dawaj znać na naszej Tutorialowej Grupie Wsparcia.
Angular CLI – czyli?
Po wejściu na stronę czytamy:
„A command line interface for Angular”
Co to oznacza?
Że z wykorzystaniem Angular CLI możemy stworzyć, a także operować naszym projektem Angularowym.
Zaczynamy pracę nad nowym projektem. Otwieramy edytor i mamy pusty folder. Na aplikację składa się naprawdę sporo narzędzi. Wszystko możemy budować krok po kroku, podpinając kolejne biblioteki, frameworki… lub wygenerować pewien projekt startowy.
Temu właśnie służy Angular CLI. Daje nam pewien początkowy zestaw narzędzi, z których możemy skorzystać.
Ale uwaga! Takie gotowce mają swoje wady. Jeśli od początku sam decydujesz co podpiąć – masz większą kontrolę niż generując projekt z podpiętym takim a nie innym zestawem narzędzi. Coś za coś. Poza serią zamierzam opisać jak można samemu złożyć projekt startowy, który teraz jednak wygenerujemy.
Projekt startowy możemy nie tylko generować. Są gotowe zalążki projektów, z których możemy skorzystać (szukaj pod boilerplate, seed). Taki „zalążek” możemy również stworzyć sami i wykorzystywać w kolejnych aplikacjach.
Co zrobić, żeby wygenerować taki projekt? Po pierwsze zainstalować sam Angular CLI.
Instalacja Angular CLI
Instalujemy go ponownie z wykorzystaniem NPM:
1 |
npm install -g @angular/cli |
Oczywiście instalujemy go globalnie (-g).
Gotowe 🙂
Tak już. Teraz możemy go wykorzystać do wygenerowania projektu.
Generowanie projektu z wykorzystaniem Angular CLI
to tak naprawdę jeden krok:
1 |
ng new NAZWA_PROJEKTU |
Przy czym możemy ustawić pewne parametry początkowe projektu. Jak wspominałam, w naszej aplikacji skorzystamy z Sass’a (ale SCSS syntax). Konieczne więc będzie dodanie opcji –style=scss.
1 |
ng new NAZWA_PROJEKTU --style=scss |
Domyślnie projekt korzysta z CSS, zamiast SCSS. Oczywiście zamiast SCSS możemy skorzystać również z Less, Stylus’a, itd.
Inne opcje dla ng new znajdziesz tutaj.
Uruchomienie projektu
Wchodzisz do folderu, w którym znajduje się projekt:
1 |
cd NAZWA_PROJEKTU |
i wywołujesz polecenie:
1 |
ng serve |
Aplikacja (domyślnie) zostaje uruchomiona pod adresem:
Voilla! Gotowe. Masz swoją pierwszą działającą aplikację Angularową.
Teraz pozostaje sprawić by była to aplikacja docelowa 😀 Ale zanim to, fajnie by było zrozumieć co wygenerowaliśmy.
Struktura wygenerowanego projektu
Nie przerażaj się! Wszystko to krok po kroku omówimy, choć niekoniecznie dzisiaj 😉
Tak naprawdę folderem, w którym spędzimy najwięcej czasu jest src/app. To tam znajdą się wszystkie komponenty składające się na naszą aplikację. Oczywiście będzie ich baaardzo dużo. Dlatego tam też wprowadzimy pewną strukturę. Ale do tego jeszcze wrócimy. Dziś przeanalizujemy tylko, co znajduje się w projekcie początkowym, bez skupiania się na folderze src/app.
Na samym dole znajdziecie pliki konfiguracyjne naszego projektu.
.angular-cli.json – główny plik konfiguracyjny projektu (jak go czytać?)
.editorconfig – konfiguracja Visual Studio Code
.gitignore – mówi o tym, które pliki nie powinny wylądować w repozytorium (nie chcesz mieć tam choćby folderu node_modules czy też plików konfiguracyjnych dla IDE, gdy każdy może korzystać z innego) – nie wiesz co to GIT? Zajrzyj tutaj.
Po podpięciu repozytorium pojawi się również folder .git. O tym również będę pisać.
package.json – zbiór wszystkich paczek, zależności wykorzystywanych w projekcie (o tym już pisałam, i jeśli nie wiesz co to za plik ani do czego służy, obowiązkowo musisz zajrzeć do wpisu o Node JS & NPM).
Jakw wygląda startowy package.json?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
{ "name": "angular-cli-sample", "version": "0.0.0", "license": "MIT", "scripts": { "ng": "ng", "start": "ng serve", "build": "ng build", "test": "ng test", "lint": "ng lint", "e2e": "ng e2e" }, "private": true, "dependencies": { "@angular/animations": "^4.2.4", "@angular/common": "^4.2.4", "@angular/compiler": "^4.2.4", "@angular/core": "^4.2.4", "@angular/forms": "^4.2.4", "@angular/http": "^4.2.4", "@angular/platform-browser": "^4.2.4", "@angular/platform-browser-dynamic": "^4.2.4", "@angular/router": "^4.2.4", "core-js": "^2.4.1", "rxjs": "^5.4.2", "zone.js": "^0.8.14" }, "devDependencies": { "@angular/cli": "1.4.1", "@angular/compiler-cli": "^4.2.4", "@angular/language-service": "^4.2.4", "@types/jasmine": "~2.5.53", "@types/jasminewd2": "~2.0.2", "@types/node": "~6.0.60", "codelyzer": "~3.1.1", "jasmine-core": "~2.6.2", "jasmine-spec-reporter": "~4.1.0", "karma": "~1.7.0", "karma-chrome-launcher": "~2.1.1", "karma-cli": "~1.0.1", "karma-coverage-istanbul-reporter": "^1.2.1", "karma-jasmine": "~1.1.0", "karma-jasmine-html-reporter": "^0.2.2", "protractor": "~5.1.2", "ts-node": "~3.2.0", "tslint": "~5.3.2", "typescript": "~2.3.3" } } |
node_modules – zależności npm zainstalowane dla naszego projektu. Jakie? O tym mówi właśnie plik package.json. O node_modules też już pisałam.
Folder node_modules potrafi zajmować naprawdę dużo miejsca. Nie wrzucaj go do repozytorium!
README.md – ten plik chyba każdy kojarzy? Najważniejsze informacje na temat projektu, choćby jak go uruchomić, jak przeprowadzać testy. Ogólnie informacje od developerów dla developerów. Zawartość README.md ląduje na stronie głównej projektu na Githubie. Zajrzyj chociaż na stronę Angular CLI:
Warto się z nimi zapoznać na starcie.
Pliki konfiguracyjne projektu TypeScriptowego:
tsconfig.json (więcej info)
tslint.json – konfiguracja lintera (sprawdzanie jakości kodu, więcej wkrótce)
tsconfig.app.json oraz tsconfig.spec.json – ponownie pliki konfiguracyjne dla projektu TypeScript’owego – dla aplikacji oraz testów (w zasadzie rozszerzenie .spec sugeruje zawsze powiązanie z testami)
typings.d.ts (więcej info)
Testy aplikacji
Tutaj bardzo krótko. Temat testów pozostawiam na końcówkę serii.
Skorzystamy z Karmy oraz Protractora.
Pliki konfiguracyjne dla testów:
karma.conf.js
test.ts
protractor.conf.js
e2e/ – folder zawierający testy typu end-to-end dla naszej aplikacji (będę o tym pisać) oraz ich konfigurację – tsconfig.e2e.json.
Główny obszar naszych zainteresowań…
src – plki źródłowe dla naszego projektu.
index.html – jeśli muszę pisać co to – cofnij się do nauki HTML5 & CSS i wróć później, dobrze radzę 😉
main.ts – ponieważ piszemy w TypeScript’cie głównym plik też będzie miał rozszerzenie .ts zamiast .js. Tu wszystko ma swój start 🙂
styles.css – pierwszy plik stylów dla naszej aplikacji początkowej.
app/ – tu znajdzie się tak naprawdę nasza aplikacja, wszystkie komponenty, widoki,
app.module.ts – najważniejszy plik naszej aplikacji, tutaj załączasz wszystkie komponenty, moduły, serwisy, składające się na aplikację (odpowiednio w: declarations, imports oraz providers). Korzystając z Angular CLI przy ich tworzeniu – automatycznie są dodawane do tego pliku.
app.component.* – pierwszy komponent naszej aplikacji.
*.component.ts – odpowiada za logikę komponentu, jego działanie,
*.component.html – przechowuje jego strukturę,
*.component.css – a tu go stylujemy.
Ponadto:
favicon.ico – ikonka aplikacji, która pojawi się w zakładce (tab) przeglądarki (obok nazwy).
polyfills.ts – przeglądarki różnią się między sobą. Ta sama funkcja użyta w jednej może nie działać w innej bądź też działać inaczej. Polyfills to takie kody, które implementują „braki” w przeglądarkach.
Kopalnią takich polyfills oraz informacji nt. używania danych funkcji na różnych przeglądarkach jest strona CanIUse.
environments/
Aplikację możesz zbudować w dwóch trybach: developmentu (domyślnie) oraz produkcyjnym. Tutaj znajdziesz ich konfigurację. Zajmiemy się tym trochę później 😉
I teraz tak: jeśli czegoś nie rozumiesz – nie przejmuj się. Wszystkie tematy poruszymy w ramach tej serii. Wcześniej czy później 🙂 Część wiedzy nie jest Ci potrzebna na tym etapie. Tworzymy prostą aplikację To do. Testy dla niej zaczniemy dopiero na końcu. Poruszymy też temat Linterów, itd. Wszystko z czasem.
Tak naprawdę każdemu z tych plików można by poświęcić cały artykuł. I to nie jeden. Starałam się dostaczyć Ci podstawową wiedzę, konieczną na tym etapie, bez wdawania się w szczegóły. Wykorzystanie generatora ma taki plus, że dużo z tych plików musiałbyś podpiąć i skonfigurować sam. I wtedy owszem – powyższe informacje byłyby zdecydowanie za skąpe.
Czy na tym kończy się rola Angular CLI? Wygenerowanie projektu?
Nie. Angular CLI dostarcza nam również narzędzi, z których skorzystamy m.in. by uruchamiać aplikację, testować ją, tworzyć kolejne komponenty (wygodnie, nie plik po pliku). Opcji jest całkiem sporo. Będziemy je omawiać już na przykładzie realnego projektu – naszej aplikacji.
Jeśli coś byłoby niejasne – śmiało dawajcie znać w komentarzach!
Powodzenia z generowaniem projektu! Wykorzystajcie tą wiedzę w praktyce. Teraz 😉