plusy za podział na modele i widoki. Niektórzy robiąc nawet w jakichś cool bibliotekach typu React, zachowują się jakby nie słyszeli nigdy o rozdzieleniu widoku od reszty i wkładają do widoków totalnie wszystko.
Jednak wydaje mi się, że interakcja z modelami wygląda jakoś dziwnie, biorąc pod uwagę nazewnictwo. Jest zwyczaj, że metody, które zaczynają się na get
zwracają jakieś dane, a u tutaj jest coś takiego:
await state.food.getFood();
state.food.getFoodData();
....
foodView.renderFood(state.food);
przy tak imperatywnym podejściu to bardziej przyjętą konwencją było fetchFood
, fetchFoodData
.
Ale i tak nie rozumiem po co to podwójne instruowanie obiektu - najpierw "pobierz jedzenie" a potem "pobierz dane jedzenia" - to raczej obiekt powinien sam wiedzieć co ma robić i kiedy pobierać dane (w ogóle śmiesznie, że niby na klasach to robisz, a i tak piszesz proceduralnie i używasz obiektów jak zwykłych struktur danych).
Czemu nie przerobić tego kodu, żeby dało się zrobić coś takiego?
foodView.renderFood(await state.food.getFood());
wtedy model sam będzie wiedział, że ma pobrać dane (chociaż i tak można się przyczepić do tego, że się nazywa get...
a odpala skutki uboczne, ale to kwestia bardziej nazewnictwa).
https://github.com/kwojtach/nutritioner/blob/f2ca906ecd01ec3195053ad155291aa168493eb1/src/js/index.js
A w samych modelach natomiast używanie luzem axios
a to raczej niezbyt dobra praktyka. Czemu model ma być świadomy tego, w jaki sposób dane się transportują przez sieć i jaka biblioteka jest używana (że akurat axios
)? Lepiej wydzielić warstwę do pobierania danych i niech modele się komunikują z tą warstwą.