Angular2 – Reactive Forms – wprowadzenie do formularzy

Angular2

Angular2 pozwala nam na stworzenie dwóch rodzajów formularzy: reactive forms (zwane też model-driven forms) i template-driven forms. Oba rodzaje znajdują się w bibliotece @angular/form. W tym wpisie przyjrzymy się pierwszej z technik tworzenia formularzy, czyli reactive forms.

Reactive forms

Reactive forms, jak sama nazwa wskazuje wspomagają reaktywny styl budowania aplikacji. Formularze tworzy się w wygodny i szybki sposób. Łatwo też możemy nimi zarządzać, bezpośrednio w klasie komponentu.

reactive forms

Poprzez formularze reaktywne stworzone zostaje swoiste drzewo. Dzięki temu zarządzanie, nawet najbardziej skomplikowanymi formularzami, staje się dużo prostsze.

With reactive forms, you create a tree of Angular form control objects in the component class and bind them to native form control elements in the component template, using techniques described in this guide.

Klasy

W formularzach w Angular2 możemy wyodrębnić podstawowe klasy: FormControl i FormGroup.

FormControl

FormControl jest bodstawowym bytem formularza. Pozwala na śledzenie zmian oraz na walidację pojedynczego pola formularza.

Przykład:

FormGroup

FormGroup to grupa instancji FormControl. Również pozwala na śledzenie zmian oraz walidację w ramach grupy.

Przykład:

Dodatkowe

Ponadto, w Angular2 przygotowano klasę FormArray. Umożliwia operowanie na indeksach tablicowych przy tworzeniu formularza. Specyfikacja wyróżnia jeszcze abstrakcyjną klasę AbstractControl.

Form Builder

Do przyspieszenia pracy znakomicie nadaje się FormBuilder. Klasa ta pozwala ograniczyć powtórzenia kodu oraz poprawić jego czytelność.

Co dalej

W kolejnym wpisie wprowadzimy teorię w ruch i zbudujemy reaktywny formularz w aplikacji Shopping Manager. Do zbudowania wykorzystamy komponenty wspomniane w dzisiejszym wpisie

 

Shopping Manager – jadłospis, produkt, przepis

data-model

Do usystematyzowania pracy nad projektem Shopping Manager, należy w tym momencie sprecyzować, jak będą wyglądać kluczowe elementy naszego systemu. W tym krótkim wpisie zastanowię się jakie pola powinien mieć jadłospis produkt oraz przepis.

Planowanie

Aplikacja Shopping Manager powinna pozwolić użytkownikowi na określenie budżetu tygodniowego. Na tej podstawie powinien być generowany jadłospis. Jadłospis zawiera zbiór przepisów, a każdy przepis zawiera listę produktów potrzebnych do jego sporządzenia.

Jadłospis – Menu

Tutaj sytuacja jest najprostsza. Jak wspomniałem wyżej, jadłospis, to zbiór przepisów. W jadłospisie kluczowe pola id, date oraz recipes.

Przepis – Recipe

Budując przepis miałem sporo wątpliwości jak powinna wyglądać jego struktura. Naturalne wydało się, by przepis zawierał listę produktów, ale oprócz tego powinien mieć informację,  ile poszczególnych produktów powinno się użyć. Sposób przyrządzenia dania to kolejna zagwozdka. Poszedłem na spore uproszczenia w tym temacie.

Pole sposób przyrządzenia, to zwykły string.

Składnik – Ingredient

Zamiast produktu stworzymy nowy byt o nazwie składnik (ingredient), który będzie mieć informację o produkcie oraz dodatkowo będzie posiadać informację o jednostce miary oraz ilości potrzebnej do skomponowania przepisu.

Produkt – Product

Produkt to rdzeń naszego systemu. Jakie pola będzie posiadać, będę weryfikować na bieżąco. Na ten moment na pewno będzie id, nazwa produktu (name), nazwę producent (manufacturer), kod kreskowy (ean), wartość energetyczna (energy), masę netto (net_weight) oraz jednostkę miary (unit_of_measure).

Dodatkowo będziemy zbierać informacje o cenie w postaci kolekcji.

Podsumowanie

Przygotowana struktura pozwoli spełnić minimalne założenia projektu. Niewątpliwym plusem jest wybór MongoDB, który zapewnia mi komfort w tym temacie i oferuje mi sporą elastyczność w ewentualnej rozbudowie. Ma to również swoje minusy, ale jak zawsze, myślmy pozytywnie.

Angular2 – HTTP – pobieranie danych – @angular/http

Angular2

W poprzednim wpisie utworzyliśmy aplikację w Angular2 z pomocą Angular CLI. W tym wpisie stworzymy prosty serwis do pobierania danych z API oraz wyświetlimy wynik naszej pracy w przeglądarce. Do komunikacji wykorzystamy paczkę Angular2 – HTTP (@angular/http).

HTTP Module

Http Module nie należy do rdzenia Angular2. Jest dodatkowym modułem wykorzystywanym do komunikacji w sieci. Aby go wykorzystać należy zaimportować paczkę @angular/http.

Generowanie serwisu

Na początku pracy wygenerujemy serwis, w którym będzie logika odpowiedzialna za komunikację z backendem: ng g s product.

Importujemy serwis w odpowiednim module oraz dodajemy go do providers.

Pobieranie danych

Do pobierania listy produktów wykorzystamy metodę list(). Tworzymy zatem publiczną metodę o tej nazwie, która zwracać będzie nam Observable: public list(): Observable<Product[]>

Następnie wykorzystujemy @angular/http i metodę get() w parametrze, której podajemy URL do naszego endpointa:

this.http.get(this.listUrl)

Dzięki metodzie map() z biblioteki rxjs uzyskamy Observable. Tamteż możemy sparsować dane, które otrzymujemy do formatu JSON:

Warto też obsłużyć wyjątek i poinformować użytkownika o ewentualnym niepowodzeniu:

Wykorzystanie serwisu

Zwieńczeniem naszej pracy będzie wykorzystanie serwisu w komponencie product-list.

Tworzymy metodę getProducts(), w której wykorzystamy stworzoną wcześniej metodę list() z product.service. Robimy na niej subscribe() i przypisujemy wynik do zmiennej products.

Wyświetlenie danych

Na koniec możemy wypisać nasze dane np za pomocą dyrektywy ngFor:

W Chromie nasze produkty przedstawiają się następująco:

Angular2 - HTTP - get products