Ten artykuł jest częścią serii Tworzenie aplikacji webowej: Krok po kroku (14 / 15)

Tak jak obiecałam, choć dużo później niż początkowo zakładałam – bierzemy się za kod.

W dzisiejszym artykule omówimy kod przykładowej aplikacji wygenerowanej z wykorzystaniem Angular CLI. Stukturę katalogów wygenerowanego projektu omawiałam już jak coś w jednym z poprzednich artykułów, dziś skupimy się na zawartości folderu src.

Wymagania wstępne:

Spisane w formie checklisty (do wydrukowania bądź podglądu/importu jako szablon Nozbe):

Checklista do wydrukowania

Szablon Nozbe do podglądu i pobrania

No i przede wszystkim: wygenerowany z Angular CLI projekt, który będziemy omawiać. Choć tutaj możesz też działać w oparciu o kod umieszczony tutaj.

Materiały do nauki oraz informacje co i jak znajdziesz we wpisie Tworzymy aplikację  webową – krok po kroku – podsumowanie aktualnego statusu & co dalej?

 

Branch, odpowiadający dzisiejszemu artykułowi: https://github.com/nettecode/todoSampleWebApp/tree/angularCliApp

 

Czym będzie ta część serii tutorialowej?

Chciałabym przedstawić proces myślowy towarzyszący tworzeniu prostej aplikacji To do. To nie będzie omawianie krok po kroku kodu gotowej aplikacji, a jej rozwijanie. Oznacza to, że kod, który zobaczycie po drodze nie będzie kodem idealnym, będziemy go poprawiać, aż dojdziemy do efektu, który chcemy uzyskać. Jeśli ktoś ma zastrzeżenia do kodu – warto by najpierw zajrzał do kodu skończonej aplikacji i sprawdził, czy błąd nadal występuje. Jeśli nie – zapewne będzie tematem jednego z artykułów, w którym go poprawimy/rozwiniemy.

Demo aplikacji docelowej (jeszcze bez dodawania nowych zadań na listę oraz podłączonego Bootstrapa): TUTAJ

Wiem, że nie zwala z nóg. Nawet z podłączonym Bootstrapem czy możliwością dodawania zadań nie będzie tego robić. Bo to nie jej zadanie. Jej zadaniem będzie uczyć podstaw. W najprostszy możliwy sposób. Wrażenie może robić np. inna aplikacja, którą buduję w oparciu o ten sam stos technologiczny – Meals Planner (z tym, że ma np. Angular Material zamiast Bootstrapa). Wrażenie będą mogły robić Wasze projekty 😉

Wiem też jednocześnie, że to raczej ostatni sezon, który będzie w formie opisowej. Następny robię już raczej w formie video. Pisanie tej serii… zajęło masakrycznie dużo czasu. Myślę, że dużo przystępniejszy byłby tutorial w formie video. Być może ten również przedstawię w takiej formie 😉

 

Jak wygląda nasza aplikacja początkowa?

Dość skromnie, prawda? Idealnie na start 🙂

Nie opisuję jak ją wygenerować. O tym już pisałam szczegółowo tutaj.

Jeśli chodzi o uruchomienie, wprowadź w linii komend:

ng serve

Aplikacja (domyślnie) zostanie uruchomiona pod adresem: http://localhost:4200/

O tym już również pisałam we wspomnianym artykule.

 

W artykule nt. Angular CLI omówiłam całą strukturę katalogów projektu. Ale wspomniałam, że do najważniejszego z nich jeszcze dojdziemy. To dziś 😉

Chodzi o folder src/app. To tu znajduje się nasza aplikacja. Reszta dotyczy tak naprawdę jej konfiguracji, dodatkowych narzędzi przydatnych w development’cie i nie tylko.

W folderze widzimy następujące pliki:

  • component.html
  • component.scss (albo .css, jeśli do generowania projektu nie wykorzystano –style=scss)
  • component.spec.ts
  • component.ts
  • module.ts

Omawianie zaczniemy od najważniejszego z nich:

AppModule

Każda aplikacja Angularowa ma przynajmniej jeden moduł „główny” (root module). Zwyczajowo nazywany jest AppModule.

Aplikacje Angularowe bazują na modułach i mają swój własny system modułów (modularity system) nazywany NgModules.

Jak wygląda jego zawartość?

Najważniejszą jego część stanowi decorator @NgModule.

Dekoratory to funkcje modyfikujące klasy JavaScriptowe, dodają dodatkowe informacje o klasach (tzw. metadane).

 Angular korzysta z wielu dekoratorów.

W naszym przypadku dekorator @NgModule określa:

  • declarations
  • imports
  • providers
  • bootstrap

Zaczynając od końca:

Bootstrap wskazuje główny komponent aplikacji, który jest wstawiany w index.html. Domyślasz się, w którym miejscu?

Tak, <app-root>.

Co zostanie umieszczone w przypadku naszej aplikacji?

AppComponent, czyli zawartość pliku app.component.html (do której jeszcze dojdziemy). AppComponent jest też domyślną nazwą dla głównego komponentu aplikacji.

Oczywiście w tablicy [] może zostać umieszczone więcej komponentów niż jeden.

Aaa! O ile możemy użyć więcej niż jednego dekoratora @NgModule, własność bootstrap powinna być ustawiana tylko w module głównym.

 

Declarations – tablica zawierająca wszystkie klasy odpowiadające za widok (view classes), należące do aplikacji: komponenty, dyrektywy i pipes (czy ktoś zna tłumaczenie „pipes” na polski? modyfikatory?).

I tak. Jeśli tworzysz nowy komponent – musisz dodać jego nazwę do tablicy deklaracji w AppModule. Jeśli skorzystasz w tym celu z Angular CLI – zrobi on to za Ciebie.

 

Providers zawiera listę wszystkich serwisów, z jakich chcemy skorzystać, tworzy ich instancje.

Zakres „widoczności” takiego serwisu jest zależny od miejsca, w którym go umieścimy.

Jeśli umieścimy je na liście providers dla NgModule modułu głównego aplikacji – instancja serwisu będzie dostępna w całej aplikacji.

Jeśli umieszczamy providers dla danego komponentu – tworzymy oddzielną instancję serwisu dla danego komponentu.

Dlaczego to jest istotne? Ponieważ jeśli umieścisz serwis oddzielnie w wielu różnych komponentach – będą to oddzielne instancje serwisu. Oznacza to tyle, że jeśli będziesz na nich działać – działasz na różnych obiektach. A zatem, zmieniając stan w serwisie A, nie zmienisz stanu w serwisie B. Jeśli chcesz by komponenty komunikowały się ze sobą z wykorzystaniem serwisu – nie tędy droga.

 

Imports określa jakich modułów potrzebuje aplikacja do swojego działania.

I tak np. widzimy, że nasza aplikacja do swojego działania potrzebuje BrowserModule.

BrowserModule jest modułem wykorzystywanym przez każdą aplikację angularową, która musi wykonywać się w przeglądarce. Angular CLI załącza go domyślnie do aplikacji początkowej.

 

Tablica Imports to jedno, ale na samym początku naszego pliku app.module.ts widzimy również:

Otóż każdy component, provider, itd. wykorzystywany w @NgModule musi być zaimportowany. Nie można wrzucić do koszyka czegoś, czego nie mamy. Musimy to najpierw dostać.

Dobrym nawykiem jest import angularowych bibliotek (@angular/cośtam) przed komponentami naszej aplikacji. I np. linijka odstępu pomiędzy.

import będziemy wykorzystywać w każdej klasie aplikacji, która będzie potrzebowała innej klasy. Import nie jest czymś wprowadzanym przez aplikacje angularowe i mam nadzieję, że na tym etapie nie muszę tego tłumaczyć w szczegółach. Jeśli jednak potrzebujesz informacji na ten temat szukaj pod hasłem Javascript modules, ew. zajrzyj tutaj.

W naszej aplikacji pojawia się również słówko export:

To dzięki temu możemy wykorzystać daną klasę, mamy do niej dostęp, możemy ją zaimportować w kolejnych klasach.

 

A skąd aplikacja ma wiedzieć, który moduł uruchomić? Plik main.ts:

 

Podsumowanie

Omówiliśmy główny moduł aplikacji, elementy, które określa. Za tydzień weźmiemy się za tworzenie naszego pierwszego komponentu i omówimy kwestie z tym związane.

Wiem, że artykuł nie jest zbyt prosty i dla części z Was zawiera wiele nieznanych pojęć. Początkowo bardzo się rozpisywałam. Nie jest to jednak kurs Angular’a. To jest tutorial tworzenia aplikacji webowej. Jeśli potrzebujecie zgłębić temat Angular v4 podawałam miejsca, w których to zrobić. Po każdym artykule będę również umieszczać listę linków z materiałami dodatkowymi.

Jeśli coś  jest dla Was niezrozumiałe – dawajcie znać w komentarzach lub na tutorialowej grupie wsparcia. Wytłumaczę 🙂 Wydaje mi się, że to jeden z cięższych artykułów, dalej będzie łatwiej 😉

 

Więcej…

Architecture Overview https://angular.io/guide/architecture

Bootstraping https://angular.io/guide/bootstrapping

NgModules https://angular.io/guide/ngmodule

 

Lektura dodatkowa:

A deep dive on Angular decorators https://toddmotto.com/angular-decorators#class-decorators

JavaScript Modules (exploringjs) http://exploringjs.com/es6/ch_modules.html

 

Ciąg dalszy za tydzień…

Series Navigation<< Bootstrap – ścieżka naukiTemplate, Component, Data Binding & nasz pierwszy komponent >>
  • Jacek Lewiński

    Świetny artykuł. Krótko, rzeczowo i na temat, bez zbędnego lania wody. Mi osobiście rozjaśnił oarę kwestii 🙂 przy okazji zapytam czy planujesz jakiś tutorial typu angular + pisanie od podstaw backendu i połączenie tego w jedną działającą aplikację?

    • Dzięki! 🙂
      Tak, planuję i takie części 🙂 Ogólnie w tym sezonie skupiamy się właśnie nad częścią Front-end’ową. Bez żadnego backendu. Następny, trzeci sezon, będzie dotyczył podłączenia backendu w formie Firebase i jego bazy NoSQL. Więc tak naprawdę bazując na kodzie aplikacji z sezonu II będzie można podłączyć różne formy Backendu.
      Wątpię jednak bym dała radę zrobić wszystko sama, więc poproszę o współpracę innych blogerów-programistów. Mam już kogoś od PHP 😉 Podejrzewam, kogo poproszę o Javę i C#. Sama wezmę prawdopodobnie Node JS. Ale to kwestia jeszcze kilku miesięcy niestety… ten sezon skończy się z grudniem/styczniem. Następny rozpocznie pewnie koło lutego. A alternatywne backendy pewnie jeszcze później…