[Krucyfiks]

Witam, pisze aplikacje w vue, uzywam również vuex i teraz pytanie, jak powinienem rozplanować zapytania do API? Zrobić moduł w vuex gdzie trzymałbym zapytanie o daną rzecz w postaci akcji, czy jednak zrobić plik api.js i eksportować funkcje które by mi zwracały co trzeba?
#webdev #vuejs #javascript

[MarcelMcOne]

@Krucyfiks: polecam vue cli i axios

[MarcelMcOne]

@Krucyfiks: Poczytaj o akcjach, mutacjach i getterach.

[Krucyfiks]

@MarcelMcOne: No przecież napisałem, że używam vuex... Chce tylko wiedzieć jakie rozwiązanie będzie lepsze.

[MarcelMcOne]

@Krucyfiks: Ja mam zawsze kilka plików (np. aktualności, strony, użytkownicy). W plikach są akcje, które wywołuję w komponentach, akcja zmienia stan przez mutacje. Stan w komponencie pobieram przez computed. Nie wiem czy jasno napisałem.

[t.....i]

@Krucyfiks:

Ja stosuje takie zasady:

- Z Vuex komunikują się tylko komponenty najwyższego rzędu. Nigdy dzieci. Komunikują się tylko za pomocą akcji.
- Tak samo z routingiem - route mogą zmieniać tylko komponenty

[veranoo]

@tylkostrimi: takie uniwersalne założenia są słabe bo to wszystko zależy od projektu

[t.....i]

@veranoo:
Uważam, że jak najbardziej jest sens tworzyć uniwersalne założenia. Nie ma sensu natomist bezrefleksyjne stosowanie ich do każdego projektu, ale warto mieć jakiś punkt wyjścia. Tak samo jak z wzorcami projektowymi (bo czym są takie założenia jak nie jakimś wzorcem?) - po to są żeby nie wymyślać koła od nowa.

Z powyższych założeń na pewno założenie odnośnie routingu nie jest uniwersalne. Podobnie, założenie mówiące o komunikacji z Vuex tylko

[veranoo]

Nie ma sensu natomist bezrefleksyjne stosowanie

@tylkostrimi: Otóż to, zakładanie sobie kagańca, bo tak nie jest dobre.

Ale np. to odnośnie normalizacji odpowiedzi API to rzecz uważana powszechnie za dobrą praktykę, podobnie jak założenie odnośnie komunikacji z API przez akcje Vuex. Tworzeniem abstrakcji dla REST API to też popularna

[Marmite]

@tylkostrimi: identyczne załozenia stosuję w apce NG2 i identyczne stosowałem przy apce Reactowej. Po prostu bardzo dobrze pasują do podejścia komponentowego, gdzie dzielimy rzeczy na komponenty-kontenery (routing, komunikacja z API) i komponenty reużywalne (prezentacja danych, reagowanie na eventy).

[t.....i]

@Marmite:
I przyznasz pewnie, że to podejście ma też swoje wady np. gdy chcesz przekazać dane z komponentu najwyższego poziomu go jakiegoś bardziej zagnieżdżonego dziecka to musisz przekazywać je każdemu komponentowi w hierarchii aż trafi do dziecka. To samo z eventami, które podróżują "w górę". Nie jest to może jakiś wielki problem, ale generuje dodatkowy, tzw. "boilerplate code". No chyba, że w reakcie to jakoś zautomatyzowali?

[Marmite]

@tylkostrimi: tak, to jest problem, aczkolwiek widziałem już sposoby jak sobie z tym radzić, chyba najczęściej oparte na znanych z iOS delegatów.