Architektura Angularowa – od czego zacząłem…

Architektura Angularowa – od czego zacząłem…

Pracę nad nowym projektem zacząłem od standardowego przygotowania bazy angularowej – architektury. Niektórzy powiedzą – architektura na front-endzie? Jak urośnie Ci aplikacja do znacznych rozmiarów to zgubisz się w natłoku plików, kontrolerów, dyrektyw. Nie polecam nikomu tworzenia projektu, który będzie miał burdel w plikach.

Architektura

Nawet do małych stron internetowych jakaś struktura powinna być. Ja zawsze tworzę jeden schemat:

  1. Folder z aplikacją – pliki angularowe, które odnoszą się do konkretnych widoków. Czyli kontrolery, moduły i widoki. Podzielone na osobne katalogi według modułów. Jeśli mam stronę internetową z zakładkami “About”, “Projects”, “Contact” to tworzę 3 foldery o tych nazwach i wrzucam do nich pliki [..].module.js, [..].controller.js i [..].view.html. to daje mi przejrzystość kodu i wiem co w którym pliku jest, a w efekcie co w którym pliku mam szukać.
  2. Folder “core” – tu mam zawsze folder “libs” gdzie znajduje się biblioteka Angular (chyba, że pobieram go z CDN), dodatkowo tworzę foldery dla współdzielonych rzeczy takich jak serwisy, dyrektywy, fabryki i konfiguracje: “services”, “directives”, “factories”, “configs”. Do configs dodaję pliki takie jak np. route.config.js, gdzie trzymam konfigurację angularowego routingu, czy material.config.js jeśli używam biblioteki Angular Material, itd.. Folder “services” służy mi do wszelkiego rodzaju serwisów, które coś liczą, zmieniają, sprawdzają lub pomagają nie pisać tego samego w wielu miejscach. “factories” mimo, że w Angular 1.x jest zbliżone działaniem do serwisów to mają u mnie trochę inną rolę: pobieranie/zapis/usuwanie danych z serwera. W takim podejściu jestem w stanie w szybki sposób podmienić endpointy aplikacji jeśli zmienił by mi się język backendowy np. z PHP na C#. Dlatego zawsze staram się, aby frontend nie był ściśle powiązany z backendem, a już na pewno żeby nie był zależny od języka backendowego. Ewentualne nieścisłości mogą pojawić się w strukturach przesyłanych danych, ale później wystarczy powalczyć tylko na tym polu, a nie na kodzie całej aplikacji.
  3. “assets” – czyli wszystko co tyczy się stylu, zdjęć, ikon, elementów graficznych. Ostatnio używam SASS, co przyspiesza i ułatwia pracę ze stylami – na niego tworzę wewnątrz katalog osobny. Następnie kompiluję do folderu CSS, aby uniknąć mieszania się styli SASS ze skompilowanym już CSS.
  4. “vendor” – folder na biblioteki/pluginy dodatkowe z “trzeciej ręki”, jeśli pojawiają się jakieś zewnętrzne dyrektywy do angulara to też wrzucam je tutaj. Oczywiście znajdą się tu też pluginy z jQuery. Łączenie angulara z jQuery nie jest złe w wersji 1.x – tylko trzeba to robić z głową.
  5. Powyższe zabiegi i ułożenie katalogów owocuje tylko jednym plikiem w głównym katalogu – index.html

Tak przygotowana architektura i jej prawidłowe utrzymanie jest w stanie uciągnąć każdy projekt frontendowy na Angular 1.x. Do tego instaluję z Node Package Managera kilka dodatków do pracy takich jak Gulp (do kompilacji SASS), http-server czy dploy (do deploy’owania projektu na serwer FTP – świetna paczka).

Nowy projekt powstał właśnie w oparciu o taką budowę – w pełni modułową, więc dalej będę też posługiwał się słowem MODUŁ jako kolejną funkcjonalnością/zakładką/podstroną aplikacji.

Aplikacja

Poprzednio mówiłem o swoim nowym projekcie. Oto update:

Moduły jakie pojawiły się na pierwszy ogień to login, register, dashboard, income, expenses, budgets. Utworzona została dla nich architektura i zostały połączone do głównego modułu aplikacji. Dodane są też wspólne komponenty jak np. notyfikacje, popupy do dodawania dochodu, wydatków i budżetów. Logowanie i rejestracja natomiast powstała na samym początku jako coś na czym opiera się system. Koniecznym jest, aby użytkownik już był zalogowany zanim doda jakiekolwiek dane do systemu. Baza danych również reaguje na to czy autoryzacja się powiodła lub nie. Zwyczajnie podstawowe aspekty bezpieczeństwa zostały spełnione, aby dalej można było zarządzać danymi użytkowników. Niektóre elementy layoutu takie jak np. menu musiało zostać przepisane z jQuery na Angulara, dlatego jest dyrektywa, która zarządza działaniem tego elementu systemu. Cała lista jest generowana dynamicznie przez wsadowy JSON, dzięki któremu mogę zmieniać parametry tej listy pozycji – takich jak dostępność, widoczność, ikony, teksty, uprawnienia. Wykresy użyte na dashboardzie też wymagały dostosowania do Angulara, żeby prawidłowo i w czasie rzeczywistym wyświetlały dane.