Webpack typescript, komponenty i  angular 1.5 - raport z frontu

Podczas tworzenia wpisu nie powstał żaden nowy framework JS Świat programowania frontendowego zmienia się w zatrważającym tempie. To, co było modne tydzień temu, dziś już trąci myszką, jest zdeprecjonowane i zastąpione przez coś nowego. Rozwój standardu Ecma, środowisko Node, czy narzędzia budowania, to tylko niektóre przykłady.

Nie zawsze trzeba ślepo podążać za trendami. Jeśli chcemy dostarczyć jakąś aplikacje w rozsądnym czasie, może warto skorzystać ze sprawdzonych i dojrzałych rozwiązań zamiast sięgać po obiecujące,jednak jeszcze nie dojrzałe nowości. Z drugiej storny nie można trzymać się standardów z przed 10 lat. Gdzie jest złoty środek?

Tak właśnie zaczęła się historia próby odpowiedzi na podstawowe pytania, jakie można mieć rozpoczynając projekt frontendowy.

Właściwie o czym trzeba dziś pomyśleć zaczynając taki projekt?

Mi przychodzą do głowy następujące rzeczy:

• Jak ma wyglądać kompatybilność z przeglądarkami?
• Jaki framework frontendowy wybrać?
• Jaki standard nazewnictwa przyjąć?
• Jakiej wersji JS użyć?
• Jaki stystem budowania?
• Jak testowac aplikacjie?

Sporo. Nie prawda?

Zacznijmy od kompatybilności z przeglądarkami - to dobry punkt wyjścia, który pociągnie za sobą kolejne decyzje. Problemem oczywiście jak od lat jest IE. Na szczęście udział użytkowników IE starszych niż wersja 10 spada, i osobiście zakładam kompatybilność z tą właśnie wersją.

Nawet stosunkowo wysoki poziom(biorąc także pod uwagę korporacje) - IE10 nie pozwala nam mieć w kodzie wynikowym najnowszej wersji standardu ECMA(JS) . Pociąga to za sobą taką rzecz: pliki JS powinny być zgodne z ECMA 5.

Nie poddawajmy się jednak tak łatwo. Pisanie w ECMA5 nie jest dziś konieczne. Możemy pisać lepiej,szybciej i efektywniej. Będziemy niestety nasz kod po napisaniu TRANSPILOWAĆ do wersji 5. Służy do tego na przykład narzędzie babel.js.

Dalszą konsekwencją jest to, że musimy mieć jakiś skrypt, narzędzie, które za nas wykona proces transpilacji. Takie narzędzie pozwoli nam także lepiej zarządzać całym procesem budowania aplikacji. Tak, tak. Obecne projekty frontendowe mają swój proces budowania.

Jak wspominałem, w świecie frontendu wszystko bardzo szybko się zmienia. Jakiś czas temu, szukając automatyzacji, postawiłbym na  Grunt JS, następnie Bower Js. Obecnie w projektach używam Webpack-a. Czy tak będzie także jutro? Nie wiem.

Webpack oferuje nam dość prosty w konfiguracji mechanizm budowania projektu, oraz dodaje ciekawe "smaczki" do naszego projektu. Niewątpliwa zaletą jest także integracja z przeglądarką i automatyczne przebudowywanie projektu. Warto wiec poświęcić trochę czasu na konfigurację i zdecydować się właśnie na ten system.

Stwierdziłem chwilę wcześniej, że nasz kod trzeba TRANSPILOWAĆ. Czyli zmienić standard z NOWSZEGO na starszy. Tu trzeba by się zastanowić, co oznacza "NOWSZY". W moim wypadku, zamiast decydować się na nowy standard, postanowiłem wybrać trzecią opcje. Typescript. Język ten daje nam możliwość korzystania z nowoczesnych standardów JS, jednocześnie dodając silne typowanie do naszego kodu. Co więcej, użycie Typescriptu niejako zachęca do pisania kodu bardziej obiektowego, który w mojej ocenie lepiej nadaje się do testowania. Typescript zdaje się zachęcać do porządkowania kodu.

Podsumujmy nasze dotychczasowe rozważania. Zdecydowaliśmy że nasz kod wynikowy powinien być zgodny z ES5. Chcemy także budować nasz projekt, w czym pomóc nam ma narzędzie webpack. Chcemy aby nasz kod był nowoczesny , dlatego zdecydowaliśmy sie na Typescripta.

Czas na kolejną trudną decyzję. Framework. Jest z czego wybierać.

Zgodnie z powyższą maksymom, zdecydowałbym się na sprawdzone w bojach rozwiązanie. Mowa o angularze 1. Leciwy już ( jak na standardy frontedowe) framework daje nam sporą bazę dodatków, dzięki czemu dostarczymy "wartość biznesową" szybciej.

Wersja 1.5 przyniosła bardzo istotną zmianę - podejście komponentowe. Technicznie nie wiele: troche konwencji, trochę smaczków, jednak zmiana w podejściu do projektowania aplikacji, daje nam możliwość nowego, świeżego podejścia do frameworka. Aby podejście komponentowe zadziałało w pełni będziemy też potrzebować routera. Angular 1 miał pewien problem z routowaniem do komponentów. Rozwiązaniem tego problemuy wydaje sie UI‑router.

Angular 1.5 pozwala także, na łatwe testowanie wykorzystując Jasmine, karmę, oraz bibliotekę angular-mocks.

Podsumujmy odpowiedzi:

• Jak ma wyglądać kompatybilność z przeglądarkami? ( >=IE10 )
• Jaki framework frontendowy wybrać?(Angular 1.5 + ui router 1.0 i podejście komponentowe)
• Jaki standard nazewnictwa przyjąć? (Typescript MS naming convention)
• Jakiej wersji JS użyć? (Typescript 2.0)
• Jaki stystem budowania?(Webpack)
• Jak testowac aplikacjie? (Karma + Jasmine + angular-mocks)

Mamy odpowiedzi na wszystkie nasze pytania. Czas na zebranie tego w solidną konfiguracje, implementację i  przygotowanie startera dla projektu.

Strasznie głupio byłoby w tym miejscu uciąć wpis. Prawda? Z drugiej strony jednak omówienie wszystkiego zajmie nam chwilkę.

Dla niecierpliwych: https://github.com/bunny1985/typescript_webpack_angular1_seed

Do następnego spotkania, lub do zobaczenia na guithubie :)