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

W poprzednich artykułach stworzyliśmy nasz pierwszy komponent dla aplikacji – listę „to do” oraz dodaliśmy do niej zadania.

W aplikacjach tego typu często poza listą „do zrobienia”, mamy również listę „zrobione”. Jak wykorzystać dotychczas stworzone komponenty i rozszerzyć aplikację o drugą listę?

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:  04-todo-model

 

Lista „Done”

Poza listą To do, mamy jeszcze listę Done. Jak ją stworzyć wykorzystując nasze komponenty?

Duplikujemy fragment odpowiedziany za dodanie listy To do (app.component.html):

oraz tworzymy listę analogiczną do To do w app.component.ts:

Efekt?

No, nie do końca o to nam chodziło. Chcieliśmy, żeby zadania wykonane były przekreślone. Ale właściwie skąd aplikacja ma wiedzieć, że zadania są wykonane?

Potrzebujemy właściwości dla zadań: statusu.

Założmy, że interesują nas tylko dwa statusy: to do i done. Możemy więc wprowadzić parametr done z wartościami true/false, opisujący stan realizacji zadania.

W tym celu musimy również nieco zmodyfikować naszą listę zadań. Poza nazwą powinna zawierać również status, a więc być obiektem zamiast string’iem.

Po pierwsze modyfikujemy więc dane wejściowe:

Po drugie todoItem component:

Musi wyświetlać task.name. Pozostawienie tam task, spowoduje wyświetlenie [Object object].

Teraz musimy przekazać dalej ten status do komponentu listy, a stamtąd komponentu elementu listy. Zaraz… my już to przecież mamy 🙂

Komponent TodoListItem dostaje na wejściu cały obiekt zadania, a więc i własność „done”. Wystarczy tylko ją wykorzystać. Na co ma mieć wpływ?

  • checkbox – zaznaczony
  • nazwa zadania – przekreślona

W przypadku pola input musimy ustawić atrybut checked na odpowiednią wartość. Skorzystamy z property binding:

W przypadku nazwy zadania – przekreślenie uzyskamy dodając odpowiednią klasę w zależności od status zadania. Możemy to zrobić z wykorzystaniem ngClass:

Oczywiście wcześniej musimy zdefiniować klasę taskIsDoneDecoration w pliku .scss:

Rezultat?

Żeby nie było za pięknie – czas nieco posprzątać.

 

Za chwilę będziemy dodawać zadania do listy. Przydałoby się wyodrębnić model takiego zadania.

Todo Model

Dla odróżnienia plik z modelem nazwiemy: todo.model.ts.

Załóżmy, że będzie współdzielony w całej aplikacji. Umieśćmy go w nowo stworzonym folderze shared.

Jak będzie wyglądał model Todo?

Korzystając z takiego modelu, tworzymy nasze zadania w następujący sposób:

Nie musimy deklarować statusu zadania. Jeśli go brakuje – domyślnie ustawiany jest na „false”. Oczywiście, jeśli chcemy by status był ustawiony na true – musimy to powiedzieć.

Oczywiście, jeśli chcemy w ogóle z niego skorzystać, musimy go najpierw zaimportować w miejscu wykorzystania:

 

Ale czy to naprawdę powinno tak wyglądać? Przecież status możemy zmieniać (done/undone). Tak naprawdę potrzebujemy jednej listy zadań, nie dwóch. Oraz sposobu by zwracać listę w zależności od danego parametru.  Za chwilę będziemy również tworzyć formularz dodawania nowych zadań, który musi operować na tej samej liście. Czegoś nam brakuje…

Czymś tym jest serwis. Którym zajmiemy się w kolejnym artykule serii!

 

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

 

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

Powodzenia!

 

P.S.

Mam pytanie: jak Ci pasuje aktualna forma tutorialu?

W planach dotyczących przyszłości bloga wspominałam, że chcę wejść na Youtube. Filmiki, tutoriale, live coding. Myślę, by w ten sposób zrealizować kolejną część (sezon III) tutorialu. Być może nawet przerobić tą. Tj. już teraz ukaże się do końca w formie pisemnej, raczej przerobiłabym ją z czasem.

Oczywiście nie byłaby to seria w 100% video. Ukazywałyby się wpisy z min. jednym filmikiem w temacie, ale do tego linki do materiałów, treści dodatkowe, fragmenty kodu, itp.

Ciekawi mnie Twoje zdanie w tym temacie. A może wolisz wersję pisemną tutorialu? Nie video? Video wbrew pozorom ma swoje minusy. Jestem tego świadoma.

Masz może do mnie jakieś uwagi? Czegoś nie lubisz w video? Na coś uważać?

Daj znać w komentarzu bądź ankiecie 🙂 (w obu miejscach również mile widziane 🙂 )

Series Navigation<< Komponent pojedynczego zadania & dyrektywa strukturalna *ngForCzas na Serwis >>
PODZIEL SIĘ
Poprzedni artykułHistoria pewnej grupy…
Następny artykułCzas na Serwis

Programistka z zawodu (od 2011), wykształcenia (od 2009) i pasji (od 2003/4 roku :P).
Aktualnie: Front-end, Back-end, Full Stack. Głównie: JavaScript & Angular. Wcześniej: C++ i Mobile (nie tylko zawodowo).
Kocha programować i pomagać. Blog jest połączeniem tych pasji.