Po wstępnych testach możliwości frameworka, pierwszych niezbyt skomplikowanych aplikacjach czas na zabranie się za właściwy projekt od prawidłowej strony. Na pierwszy ogień pójdzie architektura aplikacji.
Już przy pierwszej aplikacji zaproponowanej w poradniku autorów Ionic'a zwróciłem uwagę na pewne problemy. Przede wszystkim na brak większej architektury takiej aplikacji. Wiadomo, że nie była to ani duża aplikacja ani aplikacja, która będzie miała jakiś cykl życia. Wszystko było ładowane w dwóch plikach: index.html i app.js . Nie trudno sobie wyobrazić jakie konsekwencje i problemy może nieść taki układ przy rozwijaniu większych programów. Będąc szczerym nigdy nie miałem przyjemności z AngularJS, natomiast przewinął mi się kiedyś ReactJS. Muszę przyznać, że obydwie te biblioteki niosą ze sobą zupełnie inne podejście do pisania aplikacji. ReactJS wpływa bezpośrednio na strukturę HTML i ją tworzy, natomiast w Angularze to struktura HTML korzysta z biblioteki. Działa to w zupełnie przeciwnych kierunkach. Przyjemnie pracowało mi się z React'em, zobaczymy jak sprawa będzie wyglądać w przypadku Angulara.
Podczas tworzenia tego posta posiłkowałem się następującymi wpisami ludzi zdecydowanie bardziej kompetentnych w tym temacie ode mnie, mianowicie:
- Modular AngularJS and Ionic architecture: a first step towards AngularJS 2
- Organising Code in an Ionic Application for Beginners
- Angular Structure: Refactoring for Growth
Architektura
Tak, każdy z nas kocha to magiczne słowo. Słowo, które jest obszerne i bardzo pojemne. Z racji mnogości rzeczy, które może określać wyjaśnię co będzie określać w tym poście.
Wyraz architektura w kontekście tego posta będzie oznaczać organizację struktury katalogów oraz plików w projekcie. Najpopularniejszym podziałem aplikacji w większości języków jest model MVC. Abstrahując od tego czym jest MVC, ponieważ zakładam, że większość jak nie wszyscy wiecie o co chodzi. Jeśli nie to pewnie jest wiele zgrabniejszych opisów niż ten który mógłbym sporządzić, a który nie jest tematem tego posta.
Taki model aplikacji wymusza podział naszych plików na trzy kategorie. Inaczej pisząc wykorzystujemy podział sort-by-type czyli rozdzielamy pliki według ich typu, ich przeznaczenia.
We wszystkich podlinkowanych artykułach występuje propozycja żeby zrobić krok dalej. Wykonać podział o wdzięcznej nazwie sort-by-feature. Znaczy to nie więcej, nie mniej, że nasz dotychczasowy podział przenosimy poziom niżej i stosujemy w katalogach przeznaczonych na konkretną funkcjonalność naszej aplikacji.
Jest kilka zalet takiej organizacji struktury projektu:
- Liczba plików w katalogu jest ograniczona tylko do kilku, pojedynczych z każdego typu.
- Nawigowanie i wyszukiwanie plików potrzebnych do zmian w danej funkcjonalności jest proste.
- Pracujemy bezpośrednio z daną funkcjonalnością.
- Wiemy co reprezentuje każdy katalog. Wszystko jest jasno i precyzyjnie nazwane.
Julien Renaux, autor pierwszego z podanych artykułów proponuje konkretne rozwiązania i narzędzia potrzebne do zorganizowania i wykonania aplikacji skonstruowanej w ten sposób.
Jego podstawowymi postulatami są:
- Nie używaj Bowera.
- Używaj npm.
- Nie używaj Gulp'a.
- Stosuj CommonJS - standard modularnego organizowania aplikacji
- Używaj Webpacka - biblioteka budująca aplikację z modułów i zdefiniowanych zależności
O ile zrezygnowanie z Bowera na rzecz npm'a nie jest żadnym problemem, zrezygnowanie z Gulpa może być czymś ciekawym. Dotychczas chwaliłem sobie tą bibliotekę do tworzenia zróżnicowanych tasków zadań. Stosowanie CommonJS mamy już w miarę ogarnięte przez stosowanie reguły sort-by-feature. Natomiast Webpack jest dla mnie czymś zupełnie nowym i powoduje u mnie pewną ekscytację.
W zapoznaniu się z biblioteką pomocna będzie zapewne ich strona domowa ale również wprowadzający w temat post osoby, która o nim wspomniała. W następnym poście postaram się opisać trochę wszystko czego udało mi się na jej temat dowiedzieć.
Brak komentarzy:
Prześlij komentarz