IT eSky.pl

RSS

Czy opłaca się startować z nową aplikacją w Angularze 1.5? [„NG 1.5 z placu boju” 1/7]

Ten post to 1-sza część serii „Angular 1.5 z placu boju”, prezentującej architekturę opartej na komponentach, „gotowej na NG 2” aplikacji w Angularze 1.5, nad którą pracujemy.

Wprowadzona w Angularze 1.5 metoda module.component() może wydawać się kosmetycznym dodatkiem, jednak podejście, które ta metoda promuje (a które wykorzystujemy „do oporu”) owocuje zupełnie innym typem architektury niż opisywana w większości „klasycznych” tutoriali do Angulara, mam więc nadzieję, że uda Ci się na bazie naszych doświadczeń paru rzeczy dowiedzieć.

Spis Treści:

  • Czy opłaca się startować z nową aplikacją w Angularze 1.5? [TEN POST]
  • Aplikacja w Angularze 1.5 jako drzewo komponentów [WKRÓTCE]
  • Komunikacja pomiędzy komponentami w Angularze 1.5 [WKRÓTCE]
  • Elastyczna struktura projektu w Angularze 1.5 (architektura „fraktalna”) [WKRÓTCE]
  • Pisanie projektu w Angularze 1.5 w ES6/ES2015 [WKRÓTCE]
  • Testowanie jednostkowe komponentów Angulara 1.5 – szczegółowy przewodnik [WKRÓTCE]
  • Testy E2E opartej na komponentach aplikacji w Angularze 1.5 [WKRÓTCE]

Kontekst

Na początku roku (w połowie stycznia) mieliśmy rozpocząć zupełnie nowy, świeży projekt. Stanęliśmy przed istotną decyzją: w której wersji Angulara powinniśmy go zbudować?

Właśnie została wydana werjsa beta Angulara 2 i cały Internet aż huczał od stwierdzeń, że wreszcie nadszedł właściwy czas, by poważnie brać pod uwagę budowanie produkcyjnej aplikacji w NG 2. Była to więc z pewnością kusząca opcja. Z drugiej strony, dostępny był release-candidate Angulara 1.5 (a finalna wersja 1.5.0 czaiła się tuż za rogiem), co także wydawało się ciekawą alternatywą.

Byliśmy rozdarci pomiędzy dwoma opcjami:

  • Czy powinniśmy zabezpieczyć się na przyszłość, ale kosztem borykania sie z problemami wieku niemowlęcego Angulara 2?
  • Czy raczej powinniśmy trzymać się dojrzałej wersji 1.5, ale kosztem zmierzenia się w przyszłości z migracją do NG 2?

Nasz wybór

Jak możesz się domyśleć patrząc na tytuł tej serii, w końcu zdecydowaliśmy się na Angulara 1.5.

By zrozumieć naszą decyzję, musimy przyjrzeć się stanowi obu frameworków, jak również sytuacji i umiejętnościom naszego zespołu oraz wymaganiom projektu.

Nasze „tło”

  • W większości brak wcześniejszego doświadczenia z Angularem / nowoczesnym ekosystemem JS (dostępność dobrych materiałów edukacyjnych była więc dla nas istotnym czynnikiem).
  • Start kodowania w połowie stycznia 2016 a wydanie wersji 1.0 na produkcję planowane na połowę kwietnia (nie mogliśmy sobie więc pozwolić na czekanie, by niezbędne narzędzia osiągnęły pełną dojrzałość w trakcie trwania projektu; musieliśmy mieć pewność, że wszystkie potrzebne nam technologie i zasoby są dostępne i o produkcyjnej jakości już od startu).
  • Wewnętrzna aplikacja „back-office” (dostępność rozbudowanej biblioteki komponentów UI była więc dla nas istotnym czynnikiem by przyspieszyć development; oczywiście istnieje zatrzęsienie tego typu bibliotek, zależało nam jednak na czymś dobrze zintegrowanym z Angularem, żebyśmy nie musieli marnować czasu na własnoręczne pisanie dyrektyw-wrapperów dla komponentów takiej biblioteki).

Angular 2

Mimo, że oceniany jako dostatecznie stabilny do produkcyjnego użytku, w czasie kiedy podejmowaliśmy decyzję Angular 2 wciąż zawierał parę luk:

  • Niekompletną dokumentację (zwłaszcza „guide” dotyczący testowania, co było dla nas poważnym minusem, jako że duzy nacisk kładziemy na TDD).
  • Bardzo młody ekosystem (nieliczne „boilerplate-y” projektów, generatory yeoman-a, posty na blogach, książki, „style guide-y” itp.).
  • Brak integracji z bibliotekami UI (wszyscy „główni gracze” w tym obszarze, tacy jak Angular Material, Angular UI itp. dopiero rozpoczynali migrację do NG 2 i zdecydowanie nie byli gotowi do produkcyjnego użycia).
  • Niektóre obszary frameworka (np. animacje) wciąż jeszcze były nieco płynne.

W efekcie, mimo że core NG 2 faktycznie wydawał się być gotowy do produkcyjnego użycia, otaczający go ekosystem zdecydowanie nie.

Angular 1.5

Wprawdzie byliśmy niechętni, by inwestować w starzejącą się technologię, zwłaszcza w przypadku nowego projektu, jednak mimo to dostrzegaliśmy kilka mocnych argumentów za pójściem w kierunku NG 1.5:

  • Umożliwia on architekturę opartą na komponentach, koncepcyjnie bardzo podobną do tej, na której bazuje Angular 2 (więcej o projektowaniu aplikacji NG 1.5 w architekturze opartej na komponentach w kolejnych postach tej serii).
  • Pomimo pozornie wielkiego przeskoku koncepcyjnego, to pod maską nadal stary dobry Angular 1, integruje się więc płynnie z bogatym ekosystemem bibliotek i narzędzi NG 1.
  • Core team i community Angulara wydawało się wkładać wiele wysiłku w to, by upgrade z NG 1.5 do NG 2 był tak łatwy, jak to tylko możliwe, tak więc nasza największa obawa – zablokowanie się na technologii „legacy” – była złagodzona.

Powyższe spostrzenia przeważyły szalę i w końcu zdecydowaliśmy się na Anuglara 1.5.

Spostrzeżenia po 3 miesiącach projektu

  • Krzywa nauki dotycząca architektury opartej na komponentach i tego, jak testować komponenty NG 1.5 (więcej o tym jak testować komponenty w jednym z następnych postów) okazała się odrobinę bardziej stroma niż mieliśmy nadzieję. Tego typu architektura różni się znacząco od „tradycyjnej” architektury Angulara 1.4 i materiałów edukacyjnych jest niewiele (to jeden z powodów, dla których publikuję tą serię). Jednakże, sytuacja nie jest w tej chwili o wiele lepsza jeśli chodzi o NG 2, więc nie sądzę, że wybór NG 1.5 okazał się dla nas w tej kwestii utrudnieniem. Kluczową sprawą dla nas było „wyjście na zewnątrz” i uczenie się od innych opartych na komponentach frameworków, takich jak React.
  • Z drugiej strony, krzywa nauki związana z Angularowymi API i róznymi detalami na poziomie implementacji okazała się znacznie bardziej płaska. Do NG 1 istnieje niemal niewyczerpana ilość wysokiej jakości materiałów edukacyjnych – nauka NG 2 byłaby o wiele trudniejsza.
  • Jesteśmy niecały tydzień od naszego planowanego wydania, a ekosystem Angulara 2 wciąż nie jest dojrzały (np. nadal żadna z głównych bibliotek UI nie ma wersji pod NG 2 o produkcyjnej jakości). Tak więc, patrząc wstecz, okazało się dobrą decyzją, by nie liczyć na to, że ekosystem NG 2 osiągnie dojrzałość w trakcie trwania naszego projektu.
  • Wskoczenie z pełnym impetem w architekturę opartą na komponentach okazało się właściwą decyzją. Mimo że NG 1.5 pozwala wykorzystywać komponenty w tak wąskim zakresie, w jakim tylko chcesz, pozwolenie sobie tutaj na jakiekolwiek kompromisy uczyniłoby przyszłą migrację do NG 2 o wiele trudniejszą (wymagałaby ona dużego przeskoku mentalnego i gruntownego refactoringu architektury).
  • Nie zmigrowaliśmy jeszcze do Angulara 2 (wciąż jest na to trochę za wczesnie biorąc pod uwagę obecny stan ekosystemu NG 2), tak więc kierunek w którym podążamy jak również nasze założenia dotyczące tego, jak łatwa będzie migracja do NG 2 wciąż jeszcze są nie zweryfikowane. Jednak, z naszych obserwacji tego, jak rozwija się Angular 2, wygląda to obiecująco.

Wnioski

NG 1.5 to wciąż sensowna opcja dla nowej aplikacji, jednak musisz być bardzo ostrożny projektując jej architekturę. Pójdź w pełni w kierunku podejścia opartego na komponentach a wszystko powinno być w porządku (zajrzyj do pozostałych postów z tej serii jeśli chcesz dowiedzieć się, w jaki sposób my robimy to w naszym projekcie).

NG 2 może być lepszą opcją jeżeli wydanie Twojego projektu jest planowane na nieco dalszą przyszłość (czyli masz więcej czasu by czekać aż ekosystem wokół NG 2 stanie się bardziej dojrzały) lub jeśli Twój projekt jest naprawdę duży (i miałbyś w związku z tym masę kodu którą musiałbyś później zmigrować) – my najprawdopodobniej wybierzemy Angulara 2 do naszego kolejnego projektu, który planujemy rozpocząć w okolicy lipca. Jednak dla czegoś mniejszego i krótszego jest raczej trochę za wcześnie by rzucać się ślepo na NG 2 – a NG 1.5 jest całkiem dobrym przejściowym rozwiazaniem dla takiego projektu.

Co Ty o tym sądzisz?

Co myślisz o rozpoczynaniu budowy nowej aplikacji w NG 1.5 vs NG 2? Czy masz w tym obszarze jakiekolwiek praktyczne doświadczenia? Podziel się swoim zdaniem w komentarzach poniżej!


  • bartosz krupa

    fajnie. Piszecie w TS/ES6?

  • Oskar Kaminski

    „Niekompletną dokumentację (zwłaszcza „guide” dotyczący testowania, co było dla nas poważnym minusem, jako że duzy nacisk kładziemy na TDD).”

    Nie rozumiem dlaczego wiele osób na to narzeka. To moim zdaniem świadczy tylko o tym, że developerzy idą dziś ślepo za tutorialami do frameworków.
    Przecież TDD można śmiało stosować do każdego kodu i nie trzeba wcale w testach importować żadnych frameworkowych zależności. Wystarczy jedynie zaimportować klasę / funkcję i już można działać. Jaki guide jest do tego potrzebny?

    • Wojciech Zawistowski

      W przypadku prostej klasy / funkcji jak najbardziej. Problemy zaczynają się, jeżeli testujemy elementy mocniej oparte o framework (np. szablony, requesty http, eventy DOM itp.). Wtedy pewne elementy frameworka trzeba izolować (stubbować / mockować itp.) i często bez oficjalnej dokumentacji jak to robić (a nawet oficjalnych helperów wbudowanych we framework) jest to droga przez mękę (a niektóre testy są wręcz niemożliwe albo przynajmniej niepraktyczne do wykonania).

      Podsumowując, nie chodzi mi o dokumentację jak powinno się ogólnie robić TDD (to wiemy) ale o dokumentację typu jak zasymulować kliknięcie w przycisk w szablonie komponentu, albo jak najlepiej przechwycić dane wysyłane do serwera przy pomocy serwisu $http.

      • Oskar Kaminski

        Zupełnie się nie zgodzę. Nie wiesz co zwraca $http bez dokumentacji? Wiesz. Wystarczy wykonać 1 request lub spojrzeć w jego kod by wiedzieć. I to wszystko co jest potrzebne – co jest na wejściu i wyjściu. Nie powinniście wiedzieć jak działają te serwisy. Inaczej to nie testy UNITOWE. Serwisy frameworka mają swoje testy ;) Później będziecie chcieli przejść na angulara 2 i co z tymi wszystkimi wstrzyknięciami z angulara 1? Połowa kodu testów do wymiany bo znów będziecie pakowali zależności angulara 2?

        A co do symulacji kliknięcia… w tdd tego też nie robisz. Od tego są testy e2e, i znowu, są niezależne od frameworka.

        Wiem, że w internecie jest mnóstwo poradników pt. testowanie aplikacji w angularze. Są bo to się sprzedaje. Są bo ludzie wolą czytać zamiast myśleć. Bądźmy ponad tym ;)

Zobacz również