JavaDevMatt.pl – Mateusz Kupilas

Programista, przedsiębiorca, gamedev, bloger.

ES6, Babel i czyszczenie kodu

Dzisiaj głównie o moim pierwszym celu projektu rozwijanego w ramach „Daj Się Poznać” – systematyzowanie wiedzy związanej z JS. Zawsze był to dla mnie język, w którym czasami coś na szybko kleiłem, ale nigdy nie napisałem w nim nic konkretnego.

Jak kiedyś widziałem JS?

Pierwszą styczność z JavaScriptem miałem w okolicach roku 2006. Wykorzystałem go wtedy do tego, by mieć animowane buttony na stronie www. Skopiowałem kod odpowiedzialny za podmianę grafiki buttonu i byłem dumny z efektu. 😉

JS zawsze był dla mnie „taką małą pierdółką”, którą można było zrobić coś interaktywnego na stronie www. Nigdy nie interesowałem się szczegółami tej technologii.

Gdy pisałem prototyp projektu działałem na zasadzie: „wiem jak to zrobić w Javie – pogooglam jak to będzie podobnie w JS”. 😉 Na szczęście dzisiaj wiem znowu trochę więcej niż tydzień temu.

Czego nowego się dowiedziałem?

Nie wiedziałem, że istnieje takie coś jak ES6. Istniał dla mnie po prostu „JavaScript” i nie interesowałem się poszczególnymi wersjami, które obsługują przeglądarki (albo ich nie obsługują).

Tak po ludzku: popularna nazwa języka to JavaScript, ale gdy odwołujemy się do konkretnej wersji mówimy ECMAScript albo ES. Np. ES6 / ES2015. Powodem są prawa autorskie nazwy „Java”.

Ten film to sympatycznie tłumaczy:

Gdy googlałem za tym „jak coś zrobić coś tak jak w Javie” np. chciałem napisać klasę, do której wrzucę cześć funkcjonalności, to trafiłem na tworzenie klas w JS:

class Foo{

}

Wszystko wydaje się spoko. Problem pojawia się wtedy, gdy użytkownik nie korzysta z przeglądarki, która obsługuje ES6 (albo nie obsługuje konkretnej funkcjonalności).

By sprawdzić co gdzie jest obsługiwane można zerknąć na ECMAScript 6 compatibility table. Widzimy tam np. jak kiepsko wypada IE11 (prawie wszystko czerwone).

Co w takim razie możemy zrobić, gdy chcemy korzystać z nowej funkcjonalności (koniecznie chcę korzystać z class), ale nie chcemy stracić użytkowników?

Babel

Babel tłumaczy starszym przeglądarkom jak obsłużyć funkcjonalność nowszych wersji ECMAScript.

Przykład z wykorzystaniem class:

Tu możecie się tym sami pobawić.

By jakoś sensownie korzystać z Babel, należy go sobie skonfigurować lokalnie. Trochę z tym dłubania, ale chyba warto.

Otrzymałem na ten temat również komentarz na GitHubie. Padło tam porównanie do Mavena.

„Sam na początku myślałem, że to tylko utrudni, skomplikuje pracę, ale teraz nie wyobrażam sobie pracować bez tych narzędzi – tak bardzo pomagają w pracy, że nie masz pojęcia 🙂 Możesz sobie porównać ten proces budowania paczki do kompilacji/budowania gotowej aplikacji w Javie, a NodeJS/npm do np. Mavena.”

Co oprócz Babela?

Kiedyś obiło mi się o uszy, by w nowoczesnym JavaScripcie korzystać z let i const. Jednak nigdy się temu dokładnie nie przyjrzałem. Po raz kolejny dziękuję za pomoc społeczności na GitHubie 🙂 kolejny argument za tym, by otwierać swój kod projektów edukacyjnych (i nie tylko).

dobrą praktyką jest używanie zmiennych const i let, które działają w sposób bardziej zbliżony do zmiennych z innych języków(m.in. zasięg blokowy).

Nie mam zamiaru teraz przeczesać całego kodu i wszędzie to zastosować.

Mój plan to:

  • Pisanie nowego kodu z uwzględnieniem let i const.
  • Gdy dotykam stary kod, to poprawiam tam co mogę.

To projekt edukacyjny, na który poświęcam 3-4h tygodniowo – nie ma co się wariować. 😉

Pojawiły się również propozycje stosowania importów. Trochę się tym bawiłem, ale zaczęło pojawiać mi się trochę zależności, które musiałem przez to wrzucić (np. require.js). Nie jestem pewny, czy dla takiego małego projektu w Phaserze na pewno jest to gra warta świeczki. Możliwe, że wpadam tutaj w przedwczesną optymalizację. 😉 Postaram się jednak posłuchać bardziej doświadczonego kolegi i trochę się z tym jeszcze pobawić.

„To, że budując produkt – budujesz zależności – jest w dzisiejszym świecie nierozłączne. Ważnym jednak jest efekt końcowy, plus to, czy rozwijanie produktu jest łatwe czy też nie. Moja propozycja jest taka: pobaw się tymi klockami dłużej, napisz kilka projektów, i sam oceń – ale nie odrzucaj tego po pierwszych instalacjach, bo nie poznasz wygody tych rozwiązań.”

Efekty czyszczenia prototypu

Tu macie do wglądu kod starego prototypu. Założyłem też TAG dla stanu kodu z tego wpisu.

Głównym celem było oczyszczenie „playState”, który w starym prototypie miał 429 linijek kodu.

Aktualnie ma 286. Dużo rzeczy można jeszcze poprawić, ale liczy się dla mnie, by projekt dzisiaj był w trochę lepszym stanie niż tydzień temu. To projekt poboczny pisany na potrzeby konkursu #DSP, by czegoś się nauczyć i przeprowadzić mały eksperyment związany z monetyzacją gier webowych.

Pojawił się też pierwszy Pull request! Dzięki Marcin. 🙂

Obecna struktura plików projektu:

Co za tydzień?

Przyjrzę się jeszcze trochę tym importom z ES6, które wymagają require.js. Oprócz tego postaram się zaimplementować w końcu gamepad i obsługę urządzeń mobilnych.


6 thoughts on “ES6, Babel i czyszczenie kodu

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *