To nie przelewki

Pora ogarnąć strukturę modelu, żeby wraz z rozwojem funkcjonalności w aplikacji (już za chwileczkę, już za momencik), nie zapanował CHAOS. Mądrzy ludzie prawią, że lepiej to zrobić wcześniej niż później, dlatego zabieram się za to już teraz, gdy wspomnianych funkcjonalności mam zaledwie cztery - a raczej jedną, w czterech wariantach, polegających na wyświetlaniu listy:

• wszystkich książek
• książek papierowych
• e-booków
• audiobooków

Więc co z tym modelem?

Model odpowiada za dostęp do danych (u mnie - do REST API, o którym niebawem też napiszę). Na potrzeby mojej aplikacji (przypomnę - niewielkiej i skromnej :)) wystarczy, że będzie odzwierciedlał zasadę CRUD - z ang. create, read, update, delete (pol. utwórz, odczytaj, aktualizuj i usuń).

Akronim CRUD odpowiada czterem podstawowym metodom http:

• Create = POST
• Read = GET
• Update = PUT
• Delete = DELETE

W BUCE będą następujące funkcjonalności (CRUD 1:1):

• dodawanie nowej książki (create)
• wyświetlanie informacji o książce i książkach - wszystkich oraz wybranych według filtrów (read)
• aktualizowanie informacji o książce (update)
• usuwanie książki (delete)

REST API mam dostępne pod adresem: http://localhost:3000. Tutaj będą kierowane wszystkie żądania do API, dlatego w moim modelu tworzę zmienną API_URL, do której przypisuję tenże adres. To pozwoli w przyszłości zaoszczędzić nieco na "kopiuj-wklej".

Kolejnym krokiem jest rozpisanie metod http obsługiwanych ajaxem:

💡Tutaj ważna (dla mnie, do zapamiętania) kwestia:

Funkcja getCollection zwraca listę wszystkich książek albo listę książek wyfiltrowanych według typu (papierowa, e-book, audiobook). Żeby filtr zadziałał, potrzebuję w URL ajaxa przekazać parametr (tenże filtr): bookTypeId. Dzięki temu dostaję z API odpowiedni zasób - dostępny pod jednym z poniższych adresów URL:

• http://localhost:3000/books?bookTypeId=1
• http://localhost:3000/books?bookTypeId=2
• http://localhost:3000/books?bookTypeId=3

Mamy tu do czynienia z tzw. query stringiem (to, co rozpoczyna się ? i następuje po nim). I teraz meritum zagadnienia:

💡Żeby skleić poprawny URL (odpowiadający jednemu z trzech powyższych), przekazywany parametr (bookTypeId) musi być obiektem, dodanym po przecinku. jQuery bierze z tego obiektu klucz oraz jego wartości - i z tej pary składa query stringa (np. ?bookTypeId=1), a następnie dokleja go do hosta i ścieżki (localhost:3000/books).

Jeśli zamiast obiektu użyję liczby - jak poniżej,

to JavaScript zrzutuje liczbę do stringa (zachodzi tu - gdybym miała popisać się znajmością teorii ;) - koercja typów implicite). W wyniku tego powstanie niewłaściwy URL: http://localhost:3000/books1, a server zwróci błąd 404:

Jeśli parametr będący liczbą umieszczę po przecinku (jak obiekt):

to zostanie zignorowany. I mimo przekazywania go, server za każdym razem będzie zwracał zasób dostępny pod adresem http://localhost:3000/books (czyli filtr nie będzie działał).

Jeśli zaś parametr będący obiektem umieszczę po znaku + (jak liczbę):

to JavaScript znów zrzutuje go do stringa i w efekcie otrzymamy niewłaściwy URL (http://localhost:3000/books[object%20Object]) oraz błąd 404:

Jaki z tego morał?

Trzeba uważać na typy w JS i wiedzieć, co w trawie piszczy. ;) Ja nie do końca wiedziałam, dlatego ten post taki długi - żeby się poskładało i utrwaliło. Amen.