Moduły node.js – I have no idea what I’m doing!

Muszę się do czegoś przyznać. Tak naprawdę, nigdy nie napisałem żadnej konkretnej aplikacji używając modułów node’a. Znam teorię, wiem jak działają ale nie mam najważniejszego – doświadczenia. Dlatego zanim rozpocznę właściwą pracę nad projektem Daj Się Poznać, chciałem stworzyć mini projekt testowy. Tak na rozgrzewkę.

Początkowo nie miałem opisywać go na blogu. Jednak gdy skończyłem, doszedłem do wniosku, że lepiej podzielę się ze światem wynikami mojej pracy. Głównie dlatego, że nie wiem czy robię to dobrze 🙂 . A tak może ktoś zwróci uwagę na ewentualne błędy lub potwierdzi, że wszystko jest ok.

Moduły node.js javascript noob

Celem projektu było stworzenie prostej implementacji klasycznej gry snake. Chciałem popracować z modułami node’a w połączeniu z najważniejszym dla mojego projektu elementem canvas. Napisanie prostej gry było idealnym rozwiązaniem.

Gra jest bardzo prosta i posiada tylko jeden stan. Wąż porusza się, reaguje na przyciskanie strzałek, zjada pojawiające się losowo jabłka, rośnie i przyśpiesza. Jeśli nastąpi kolizja węża z jego ogonem lub z krawędzią pola gry, gra resetuje się.

Tym razem udostępniam tylko paczkę z kodem. Wewnątrz są wszystkie pliki i moduły używane podczas tworzenia programu (łącznie z moim package.json). Aby zagrać wystarczy uruchomić w przeglądarce plik index.html. Gra nie jest działająca w stu procentach. Jednym z problemów jest na przykład to, że można bardzo szybko przycisnąć odpowiednie strzałki, co powoduje, że wąż włazi sam w siebie. Możliwe, że są też inne. Ale nie o to chodziło, żeby było idealnie. Chodziło to żeby działało 🙂

Projekt podzieliłem na moduł wejściowy (main.js), główny moduł gry (game.js), moduły konfiguracyjne (canvas.js, helpers.js, keys.js) oraz moduły obiektów gry (snake.js, apple.js).

Wszystko to za pomocą Browserify upycham do pliku bundle.js, który z kolei dodawany jest do index.html.

Zacznę od pliku wejściowego czyli main.js:

Jak widać, nic wielkiego. Po prostu pobieram moduł game i uruchamiam jego funkcję init.

Kolejny moduł to właśnie game. Jest to główny obiekt gry. To tutaj znajduje się pętla odpowiadająca za przebieg rozgrywki:

Na początku ładuję wszystkie moduły i przypisuję je do odpowiednich zmiennych. Dalej znajdują się funkcje nie będące częścią obiektu exports. Pierwsza z nich to startLoop. Wywołuje ona rAF, w którym z kolej wywoływane są funkcje updateGame oraz drawGame.

Następna funkcja to initGame. W niej inicjalizowane są moduły keys oraz snake. Każdy z nich ma własną funkcję init. Przypominam, że aby można było użyć funkcji z zewnętrznego modułu, musi ona znajdować się w obiekcie exports tego modułu 🙂 Będzie to ładnie widoczne gdy przejdę do konkretnych modułów. w funkcji initGame wywoływana jest też startLoop, co wprawia grę w ruch.

Kolejna funkcja to drawGame. Najpierw czyszci pole elementu canvas. Następnie, jeżeli funkcja isOnScreen modułu apple zwróci true, wywoływana jest funkcja draw tego samego modułu. Na koniec zawsze wywoływana jest funkcja draw modułu snake.

Ostatnia ‚prywatna’ funkcja to updateGame. Jest ona najdłuższa ale wcale nie bardziej skomplikowana. Pierwsza część funkcji to cztery wyrażenia warunkowe. W każdym z nich sprawdzam za pomocą funkcji isPressed modułu keys czy wciśnięta jest któraś ze strzałek. Jeżeli tak i jeżeli nie jest wciśnięta przeciwna strzałka i jeżeli wąż nie porusza się w przeciwnym kierunku (funkcja getDirection modułu snake), zmieniam kierunek poruszania się węża (funkcja setDirection modułu snake). W kolejnej części funkcji przy pomocy isOnScreen modułu apple, sprawdzam czy jabłko znajduje się na planszy. Jeżeli nie, wywoływane są funkcje spawn i setOnScreen tego samego modułu. Ta druga funkcja jako parametr otrzymuje wartość boolowską true. Gdy jest to już gotowe aktualizuję węża wywołując metodę update modułu snake.

Pozostała część kodu updateGame to wywołanie dwóch funkcji modułu helperscheckApple oraz checkCollision. Pierwsza sprawdza, czy wąż nie zjadł przypadkiem jabłka a druga, czy nie wszedł w swój ogon. Jeżeli warunek pierwszej funkcji zostanie spełniony, jabłko znika z planszy (funkcja setOnScreen(false) modułu apple) a wąż rośnie (funkcja grow modułu snake) i przyśpiesza (funkcja quickenSnake modułu snake). Jeżeli warunek funkcji checkCollisions będzie prawdziwy, wąż jest resetowany a jabłko znika z planszy.

Na końcu modułu game znajduje się obiekt exports, który otrzymuje tylko jedno pole – init. Jest to funkcja w który wywoływane jest initGame. I to cały moduł :).

Teraz przyjrzę się modułom z folderu config. Pierwszy z nich to canvas

W tym module po prostu pobieram element canvas z DOMu a następnie w obiekcie exports ‚upubliczniam’ jego najczęściej używane właściwości. Znajdują się tu wymiary płótna, kontekst, oraz bezpośredni odnośnik do płótna.

Kolejny moduł konfiguracyjny to keys:

Ten moduł służy do obsługi przyciskanych na klawiaturze klawiszy. Posiada dwie zmienne, pierwsza z nich to obiekt pressedKeys, który na początku jest pusty. Druga zmienna to keys. Ona też zawiera obiekt, którego pola to nazwy przycisków a właściwości to ich kody.

Moduł posiada dwie funkcje przekazywane są do obiektu exports. Pierwsza z nich to init. Sprawia ona, że po wciśnięciu klawisza jego kod trafia do obiektu pressedKeys. Po puszczeniu klawisza, odpowiednie pole wspomnianego wcześniej obiektu jest kasowane. Nic nowego, ten mechanizm pojawiał się w moich programach już wiele razy.

Druga eksportowana funkcja to isPressed. Przyjmuje ona jeden parametr. Będzie to nazwa przyciśniętego klawisza. Jeżeli w obiekcie pressedKeys, znajduje się kod, który pasuje do tej nazwy, zwracane jest true, w przeciwnym razie, funkcja zwraca false.

Ostatni moduł konfiguracyjny to helpers. Trafiły do niego wszystkie funkcje użytkowe, których nie mogłem za bardzo umieścić nigdzie indziej a nie pasowały mi w module game. Oto treść helpers:

Ten moduł to tak naprawdę tylko dwie funkcje, obie znajdują się w obiekcie exports. Pierwsza z nich, checkApple, przyjmuje w parametrach potrzebne jej właściwości węża i jabłka a następnie sprawdza czy nie następuje między nimi kolizja. Jeżeli tak zwracane jest true, w przeciwnym wypadku false.

Druga funkcja checkCollisions, również otrzymuje jako argumenty potrzebne jej dane. Sprawdza czy ‚głowa’ węża nie koliduje z którymś z pozostałych jego elementów oraz czy nie znalazła się poza granicami płótna. Jeśli któryś z powyższych warunków zostanie spełniony, funkcja zwraca true, W przeciwnym razie zwracane jest false.

Ostatnie dwa moduły przedstawiają ‚bohaterów’ gry. Pierwszy z nich to snake:

To najdłuższy moduł programu ale tak jak i poprzednie nie zawiera żadnej skomplikowanej logiki.

Na początku znajdują się zmienne związane z wężem:

  • body – tablica przechowująca obiekty reprezentujące segmenty węża.
  • segmentSize – rozmiar węża w pikselach.
  • length – ilość segmentów węża.
  • currDirection – aktualny kierunek, w którym podąża wąż.
  • framesToMove – liczba klatek co którą wąż się porusza.
  • lastMove – licznik zawierający informacje ile klatek wąż się nie poruszył.

Następnie pojawia się jedna funkcja ‚prywatna’ moveSnake. Zawiera ona logikę poruszania się węża. Nie będę jej opisywał dokładnie ponieważ już raz to zrobiłem. Jest ona identyczna jak w mojej poprzedniej implementacji węża 🙂 .

W obiekcie exports znajduje się dość sporo funkcji. Pierwsza z nich to init. Wypełnia ona tablicę body odpowiednią ilością obiektów reprezentujących segmenty ciała węża. Obiekty otrzymują pola x oraz y reprezentujących położenie danego segmentu. Początkowo wąż znajduje się w lewym górnym rogu i porusza się w prawo.

Następne cztery funkcje to zwykłe ‚getter’y’, które zwracają wartości prywatnych zmiennych modułu. Są to getDirection, getLength, getSize oraz getBody. Kolejna funkcja to ‚setter’ – setDirection. Ustawia ona wartość zmiennej direction na tę którą otrzyma jako parametr.

Kolejna funkcja draw wyrysowuje wszystkie elementy węża na płótnie w odpowiednich pozycjach. Wskaźnik do kontekstu płótna przekazywany jest w argumencie funkcji.

Funkcja update wywołuje prywatną funkcję moveSnake jeżeli wartość lastMove równa jest framesToMove. W przeciwnym razie wartość lastMove jest inkrementowana.

Funkcje grow oraz quickenSnake wywoływane są gdy wąż zje jabłko. Pierwsza dodaje nowy segment do ciała węża a druga zmniejsza wartość framesToMove o dwa (z tym, że wartość ta nie może spaść poniżej 5).

Ostatnia publiczna funkcja reset odpowiedzialna jest za zresetowanie węża po tym jak gracz skusi. Ustawia ona wszystkie zmienne modułu snake do wartości początkowych i na nowo inicjalizuje węża.

I tak dotarłem do ostatniego modułu czyli apple. Oto jego zawartość:

Nie będę już dokładnie opisywał tego ostatniego modułu. Jeżeli działanie poprzednich modułów było dla czytelnika jasne, to i tu nie powinno być problemu. Tym bardziej, że logika nie różni się zbytnio od mojej poprzedniej implementacji węża.

Jest tu za to inna ciekawostka. W tym module trochę poeksperymentowałem. Nie przekazuję właściwości innych modułów w argumentach publicznych funkcji. Zamiast tego ‚rekłajeruję’ je bezpośrednio do zmiennych. Czy to dobra praktyka? Może wszędzie powinienem tak robić? Nie wiem (patrz tytuł posta), ale zadziałało 🙂 . Może są wśród czytelników ludzie bardziej otrzaskani z nodem i coś mi podpowiedzą? Byłbym bardzo wdzięczny.

I to tyle jeśli chodzi o dzisiejszy post. Nie wiem czy dobrze operuję modułami noda, ale wiem, że bardzo przyjemnie mi się z nim pracuje. Jak tylko opublikuję ten wpis, zabieram się za pisanie konkursowego projektu. Tak, w następnym wpisie w końcu pojawią się pierwsze podejścia do implementacji mojej własnej platformówki 🙂

Tymczasem zachęcam wszystkich tych, którzy jeszcze tego nie zrobili do polubienia mojej strony na facebooku. To dobre miejsce na kontakt ze mną. Zamieszczam tam też informacje o wszystkich nowościach na blogu, więc warto tam zaglądać aby być na bieżąco.

3 przemyślenia nt. „Moduły node.js – I have no idea what I’m doing!”

  1. Kolejny ciekawy wpis. Ostatnio ogarniałem nodejs i jakby zalety jego uzywania wydaję się w miare klarowne, ale zastanawia mnie jedna rzecz i ciekawi mnie co Ty o tym uważasz 🙂 Otóż moduły node posiadają wiele zależności od innych modułów, finalnie pobierając paczkę kilku modułów do niedużego projektu, i finalnie projekt waży 100 albo 200 MB i ma w sobie kilka tysięcy plików (których nawet usuwanie trwa z 1-2 min), gdzie projekt w czystym JS lub + jquery można by napisać (co prawda większym nakładem pracy i większą ilością własnego kodu) tak aby ważył np. 50 KB. Dobrych kilka lat temu na studiach uczono mnie jak ważne jest trzymanie czystości kodu, aby on mało ważył – generalnie aby robić wszystko optymalnie, a tu nagle do prostego projektu potrzebuję tysięcy plików ważących w sumie kilkaset MB.

    Jak Ty, jako bardziej doświadczony programista się na to zapatrujesz?

    Tu też ciekawy tekst o tym: https://medium.com/friendship-dot-js/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558#.31hlyjoxh

    1. NPM to ‚miejsce’, gdzie publikować może każdy a wiadomo jakie to może nieść za sobą konsekwencje. Osobiście uważam, że jeżeli jesteś w stanie napisać coś sam i nie zajmie Ci to więcej niż kilka godzin, to lepiej zrobić to samemu. Oczywiście jest sporo ‚pewnych’ paczek i nic nie stoi na przeszkodzie żeby z nich korzystać. Ale zawsze warto jest się zastanowić czy faktycznie jest mi potrzebny cały moduł. Co do podlinkowanego artykułu, nie jestem pewny czy to nie jest mały trolling :), ale dobrze sygnalizuje problem instalowania co popadnie. Najgłośniejszy rezultat takiego podejścia to afera z left-padem: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

  2. Tego projektu nie da się uruchomić na serwerze, racja? Tylko przez index.html. Mam przez to wrażenie, że pokazałeś tu w zasadzie możliwości JS, a nie node’a.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *