AngularJS - odświeżanie danych po submit

Question

Jak powinienem zrobić "odświeżanie" danych w widoku po wysłaniu ich do DB przez API?

Taka sytuacja:
- mam na stronie usera Adam, zmieniam mu imię na Ewa, robię post do API, zapisało się w DB ale na tym koniec, na stronie nie wczytało mi nowych danych, jak odświeżyć $scope.user i przekazać do widoku ponownie? Samą zmianę imienia z Adam na Ewa ok wiem ale jest jeszcze kilka innych zmian zależnie od tego jakie jest imię więc musze ponownie popchać dane $scope.user. Nie wiem jak. :) Podpowie ktoś?

Answer 1

Najprostrzy sposób - na udany POST callujesz funkcje, która robi GET (Z tego co pamiętam te funkcje w angularJS powinny być w services/factories i tylko importowane do controllerów).

Comments

Najczęściej faktycznie wywołania http umieszcza się w serwisach ale nie jest to żaden wymóg angulara, tylko ogólnie przyjęta praktyka. Generalnie lepiej jest gdy kontroler dostaje już opowiednio zmapowane wyniki na oczekiwany model biznesowy i nie interesuje się za bardzo tym, skąd te dane zostały pobrane.

---

czy moge to rozumieć tak:?

- serwisy to "funkcje" które mają dostep do kontrolerów a kontrolery do serwosów (set, get) (bo kontrolery chyba nie widzą się pomiędzy sobą) i takie pobieranie danych z DB powinienem dawać do serwisu który to poda "wszędzie"  gdzie zostanie wywołany? Wtedy w kontrolerze po submit mogę ponownie wywołać serwis i mieć nowe dane.

---

zarówno kontrolery i serwisy to po prostu zwykłe klasy JS'owe, odpowiednie dekoratory pozwalają im na prawidłową pracę z całym Angular, to tak w bardzo dużym uproszczeniu.

Generalnie serwisy powinny odpowiadać bardziej za logikę biznesową, natomiast kontroler powinien tylko pobierać dane od serwisu i przekazywać je do templatki. Oczywiście nie zawsze jest to takie czyste, nierzadko logika wchodzi również do kontrolera, szczególnie gdy np. kilka kontrolerów pobiera te same dane z serwisu ale potem różnie je dodatkowo obrabia. Można co prawda zawsze dyskutować czy nie zrobić w tym momencie np. bardziej konfigurowalnej metody w serwisie, czy dodać tam kolejne itp. ale jak to w życiu bywa to wszyscy wiedzą... jeden zrobi tak, drugi inaczej :) a w CR nie zawsze jesteś w stanie wszystko wyłapać.

Generalnie to ja bym na to patrzył z innej strony. W serwisie np. obsługujesz bezpośrednio strzały do API i zwracasz do kontrolera konkretnie te dane, których on oczekuje. Kontroler czasami roi sobie jeszcze jakąś swoją mniejszą logikę, np. jakieś dynamiczne sortowania itp. itd. ale nie wtrąca się w komunikację z API. Na przykład przy zapisie daych z formularza logikę validacyjną najczęściej robię w kontrolerze (np. reactive forms z sync/async validators jako osobne klasy/metody itp.), a następnie wywołuję metodę typu someService.updateData(data), który to już odpowiada za strzał do API i zwrócenie np. statusu ok/error co znowu kontroler odpowiednio może przekazać do templatki i np. wyświetlić modala na pół strony "hej, kurde mamy problem, wróć do nas za 5 minut" :)

 

No i zawsze, ale to zawsze patrz na kod pod kątem testów. To naprawdę niesamowicie ułatwia pisanie i czytanie kodu. Pisząc jakąś metodę myśl jak będą wyglądały do niej testy, przez to nie napiszesz metody na 50 linijek... Oczywiście można mówić też o TDD, ale to później, i na froncie nie zawsze się to tak do końca sprawdza... przynajmniej mi jakoś łatwiej pracować z TDD gdy zmieniam API niż na froncie, gdzie czasem w trakcie wychodzi wiele rzeczy... zmian UX itp. itd.

---

wow, super :) Dziękuję za tak konkretną odpowiedź, miło się czytało i staje się bardziej jasne. Możesz mi jeszcze podpowiedzieć jak powinienem sobie zobrazować i zrealizować taka oto prostą sytuację (prostą ale nie wiem jak poprawnie zrobić):?

- daję "submit", idzie do DB, w .success(...) odświeżam dane i chcę wyświetlić informację dla klienta, że poszło ok - robię to tak:

$scope.success = true;
$timeout(function(){
 $scope.success = false; }, 1000);

i w divie daję ng-if="!success"

tym wywołuje informację - poprawnie? (działa więc teoretycznie tak) ale zależy mi na tym abym wiedział jak to robią inni, jak powinno się robić czy co jest dobrą praktyką.
Dziękuję.

---

i tak i nie... generalnie droga dobra, oczywiście $timeout zamieniamy na resolve promisa :) ale może lepiej np. tak:

public shouldShowInfoModal: boolean;
public infoModalMessage: string;

// strzał do API, dla onSuccess robimy:
this.shouldShowInfoModal = true;
this.infoModalMessage = 'OK';

// a dla błędu odpowiednio zmieniamy message

// w templatce możesz wtedy pokazanie modala
// uzależnić od zmiennej i odpowiednio przypisać mu np. message

Generalnie są lepsze metody na takie operacje, i raczej powinno się dążyć do robienia bardziej uniwersalnych komunikatów dla całej apki ale to już są szczegóły implementacyjne.

Answer 2

Jeśli robisz update to pewnie PUTem, więc możesz w zwrotce sobie przesłać nowe dane i po prostu po otrzymaniu response w angularze dokonaj aktualizacji odpowiednich pól. Niezbyt rozumiem pytanie, sprecyzuj w którym dokładnie momencie masz problem?

Comments

chyba z tym poradziłem ale nie wiem czy to tak się robi. pierwszy raz jak pobieram dane usera to mam to w zmiennej:
$scope.dane = $http.get.... - no i nie miałem jak tego ponownie wywołać po "submit" - teraz dałem to w funkcji i wywołyję funkcję kiedy potrzebuję - poprawnie?

$scope.dane = function(){$http.get....};

A chodziło mi o to, że nie miałem jak tego aktualizować bez przeładowania strony.

---

$scope.dane = function(){$http.get....};

co Ty tu w ogóle chcesz przekombinować Kolego...? Proponuję najpierw poczytać dokumentację frameworka, ja nie wiem, że masa ludzi tu chyba omija dokumentacje najdalej jak się da, a potem są problemy... Zrób to normalnie, czyli np.:

$scope.data = {}; //początkowo mamy pusty obiekcik

// teraz pobieramy dane na starcie, najlepiej wg mnie np w hooku onInit:
$http.get(URL)
  .then(response => $scope.data = response)
  .catch(err => { /* jakaś obsługa błędu */});

// gdzieś tam robisz aktualizację:
$http.put(URL, data)
  .then(res => $scope.data = response)
  .catch(err => { /* jakaś obsługa błędu */});

pracuj z promisami, nie kombinuj pod górkę skoro masz takie "narzędzia" by default z angulara...

https://docs.angularjs.org/api/ng/service/$http

tu masz wg mnie 101% potrzebnych informacji na temat pracy z $http w angular oraz np. httpBackedn do testowania, bo tutaj zapewne w ogóle nie robiłeś testów bo by te problemy wyszły prawda? :)

---

Zapisy podobne do Twojego, czyli przypisywanie od razu do zmiennej np.:

public data: Observable<Articles[]>;

constructor (private articlesService: ArticlesService) {}

ngOnInit(): void {
  this.data = this.articlesService.getAllArticles();
}

są dopuszczalne, a nawet stosowane ale to w Angular 2+ gdy nie pracujemy bezpośrednio z Promisami ale z Observable, a i to przy założeniu, że potem w templatce użyjemy async pipe, bo inaczej to musimy ręcznie robić subscribe i unsubscribe np. w hooku ngOnDestroy().

---

No i tu robi się trudniej bo z tego już mało zrozumiałem. Wiem, że dokumentacja to podstawa ale osoba początkująca z danym zagadnieniem (w tym wypadku angularjs) i do tego gdzieś tam na początku programowania ma problem z czytaniem tego - w jednym zdaniu jest tyle nowych rzeczy, że nie sposób tego ogarnąć :). Wyobraź sobie (tylko proszę nie odbieraj tego jako atak a próbę pokazania mojej strony), że masz zacząć od dokumentacji (co tu mogłoby być dla Ciebie trudne, no nie wiem, np. robienie zupy :) ) - w dokumentacji wszytko jest opisane, przeczytałeś wszytko w 100% - zajmuje to 2 miesiące, teoretycznie próbujesz to zrozumieć. Zaczynasz gotować, dajesz wszytko idealnie - zupa jest niejadalna. Dlaczego? Bo trzeba nabrać doświadczenia, nie mogłeś wiedzieć, że w tym rejonie Polski woda jest bardziej twarda i w połączeniu z taką ilością soli wyjdzie kupa, następnym razem to samo - kurcze, myślisz czemu - 100 razy to robisz i zawsze źle - bo nie rozumiesz dokumentacji mimo tego, że rozumiesz co czytasz.
Długi przykład i na pewno bardzo trudny do porównania, możliwe, że nietrafiony. Chcę pokazać, że muszę zacząć pisać z błędami i prosząc o pomoc Ciebie nabieram doświadczenia i lepiej rozumiem dokumentację. Jeśli chciało Ci się doczytać do tego miejsca to jestem pełen podziwu. Dzięki. Oczywiście jeszcze nie robię testów - zupełnie tego nie znam, to początek mojej przygody. Dodam też, że robię to na AJS 1.3.15 - bo taki trafiłem kurs. :)

---

Spoko, wiadomo, wszystko po malutku. A tak w ogóle to jeśli dopiero zaczynasz to powiedz mi dlaczego angularJS a nie Angular? Szczerze to rozumiałbym naukę angularaJS tylko w jednej sytuacji, gdy wchodzisz w taki projekt / idziesz do pracy gdzie w tym piszą. W innej sytuacji lepiej ucz się Angular 7, i tutaj dokumentacja to już w ogóle prowadzi jak za rączkę, jeszcze lepiej niż w angularJS :) Osobiście pracuję i w angularJS, i w Angular 7, a nawet w projekcie hybrydowym angularJS->upgrade to Angular 7 i niezbyt chętnie wchodzę w angularJS... naprawdę polecam Angular 7, dużo przyjemniejszy framework :)

Jest też React, ale tego to już w ogóle nie lubię i nie polecam :P, jak mam coś zmieniać w projektach Reactowych to robię to naprawdę niechętnie... jest też Vue, ale nie pracowałem z tym i szczerze mówiąc to mało kto z moich znajomych wypowiada się o tym pozytywnie i w sumie każdy potwierdza, że Vue to raczej taka zabawka do mniejszych apek.

---

https://www.udemy.com/angular-kompletny-kurs-od-podstaw/

kiedyś dostałem dostęp do tego kursu na jakiś krótki czas i pobieżnie go przejrzałem i pamiętam, że całkiem spoko się wydawał. Co prawda troszkę kosztuje, ale tak na pierwszy rzut oka wydaje mi się ok dla początkującego, a czy warto wydać 99zł to już wiadomo, osobista sprawa. Ale ktoś mi mówił, że jakieś wybrane odcinki ten gość chyba też na youtube daje, poszukaj sobie.

---

Dziękuję pięknie, na angulara 7 przyjdzie czas, teraz muszę zapoznać się z AJS - jest w firmie. :)