Ten artykuł jest częścią serii Tworzenie aplikacji webowej: Krok po kroku ([part not set] / 19)

W poprzednich artykułach stworzyliśmy nasz pierwszy komponent dla aplikacji – listę to do oraz dodaliśmy do niej zadania. Następnie rozszerzyliśmy aplikację o listę zadań zrobionych, korzystając z stworzonych wcześniej komponentów.

Nie obeszło się jednak bez pewnych modyfikacji dotyczących samych zadań (status: to do/done). Stworzyliśmy model naszego zadania i doszliśmy do wniosku, że czegoś jednak nam brakuje. Czego? O tym dzisiaj 🙂

Wymagania wstępne:

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

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:  05-todo-service

 

Serwis!

Jeśli pewna część aplikacji ma być dostępna dla więcej niż jednego komponentu – korzystamy z serwisów.

Jaka część naszej aplikacji powinna być współdzielona? Oczywiście lista zadań. Wszystkie nasze zadania powinny znaleźć się w serwisie. To on powinien zwracać zadania do zrobienia, przedstawiać skończone, odpowiadać za zmianę statusu czy też reagować na dodanie nowych zadań do listy.

Przenieśmy zatem naszą listę do nowo stworzonego serwisu:

Sama lista jest elementem prywatnym, ale możemy ją pozyskać korzystając z metody getTasks().

 

Jak skorzystać z serwisu w naszym komponencie?

Żeby skorzystać z serwisu potrzebujemy trzech rzeczy:

  • zaimportować go
  • dodać do providerów dla danego komponentu (bądź modułu)
  • wstrzyknąć w konstruktorze danej klasy
 

Teraz możemy go wykorzystać, odwołując się do niego poprzez this.todoService:

 

Jak pozyskać różne typy zadań?

Mamy metodę pozyskującą wszystkie zadania z naszej listy. Jednak my mamy dwie listy: To do i Done, a getTasks() zwraca wszystkie zadania. Jak to rozwiązać?

Może się wydawać, że mamy dwa sposoby rozwiązania:

  • pobierz wszystkie todos i filtruj je po stronie komponentu
  • pobierz przefiltrowane pod kątem statusu zadania

Lepiej jednak rozszerzyć serwis by zwracał nam to, o co chodzi niż filtrował pozyskaną listę w komponencie. Unikniemy redundancji.

Żeby zachować pewną konsekwencję, metody nazwiemy odpowiednio:

  • getTasks() – lista wszystkich zadań
  • getTodos() – zwraca listę zadań do zrobienia
  • getDoneTasks() – zrobione
Omówienie metody .filter() (jeśli nie znasz – lektura obowiązkowa!).

Teraz możemy pozyskać obie listy zadań:

Gotowe.

 

Zmiana stanu zadania

Część dotyczącą wyświetlania listy zadań mamy już za sobą. Spróbujmy zaznaczyć zadanie na liście To do:

Jak widzimy checkbox jest zaznaczony, ale nasze zadanie nie zmieniło pozycji, nie zostało też przekreślone. Dlaczego?

Ponieważ nie obsługujemy zdarzenia zmiany wartości checkbox’a. Informacje pobieramy jednostronnie:

Musimy zareagować na zmianę stanu checkbox:

Podmieniamy jedynie status zadania na przeciwny:

Rezultat?

Ok. Jak widzimy status się zmienił (nazwa zadania jest przekreślona), ale listy nadal pozostają bez zmian. Dlaczego?

Otóż przy starcie aplikacji pobierane są przefiltrowane listy. Nie nasłuchujemy na kolejne zmiany. Skąd aplikacja ma wiedzieć, że chcemy, by listy były aktualne? Trzeba jej o tym powiedzieć.

Jak? Możemy się zasubskrybować na zmiany w serwisie.

 

EventEmitter

Tak naprawdę Event Emitter zasługiwałby na caaały oddzielny artykuł. Jednak tak jak wspominałam – jest to tutorial tworzenia aplikacji webowej z wykorzystaniem Angular v4. Nie kurs samego Angular v4. Gdyby tak było każdy artykuł zawierałby pięć razy więcej treści. Zakładam więc, że masz podstawową wiedzę na temat Angular v4. Jeśli nie – sięgnij po jeden z polecanych materiałów do nauki (Angular v4 na start).

Tworzymy EventEmitter (dokumentacja).

Kiedy następuje zmiana wysyłamy sygnał do serwisu z miejsca wystąpienia zmiany.

Oczywiście, ważne jest by oba komponenty działały na tej samej instancji serwisu. W tym momencie tak jest. Serwis wstrzyknięty jest do komponentu AppComponent, więc wszystkie komponenty będące w hierarchii pod nim – będą korzystać z tej samej instancji serwisu.

Wysyłamy więc informację o zmianie statusu zadania, serwis ją odbiera. Pora odebrać ją w komponencie. Zrobimy to implementując interfejs OnInit:

który oczywiście musimy najpierw zaimportować:

 

Nasza aplikacja właśnie stała się bardziej “reaktywna” 😉

Pozostało nam jeszcze jedno: dodawanie nowych zadań do listy. Ale tym zajmiemy się w kolejnym artykule serii 😉

 

Przypominam, że kod aplikacji po dzisiejszej lekcji znajdziesz na Github’ie, branch: 05-todo-service

 

W razie pytań – śmiało dawaj znać w komentarzu lub na naszej Tutorialowej Grupie Wsparcia na Facebooku.

Powodzenia!

Series Navigation