Angular 6 - Dlaczego warto używać @ ngrx / store zamiast wstrzykiwania usługi

Niedawno uczę się Angulara 6 z @ ngrx / store, podczas gdy jednym z tutoriali jest użycie @ ngrx / store do zarządzania stanem, jednak nie rozumiem korzyści z używania @ ngrx / store za kulisami.

Na przykład dla prostej akcji logowania i rejestracji, poprzednio przy użyciu usługi (nazwijmy ją AuthService), możemy użyć jej do wywołania interfejsu API zaplecza, przechowywania „userInfo” lub „token” w usłudze AuthService, przekierowania użytkownika do „HOME” page i możemy wstrzyknąć AuthService w dowolnym komponencie, w którym potrzebujemy uzyskać informacje o użytkowniku za pomocą DI, który po prostu obsługuje wszystko w jednym pliku AuthService .

Teraz, jeśli używamy @ ngrx / store, musimy zdefiniować Action / State / Reducer / Effects / Selector, który prawdopodobnie musi zapisać 4 lub 5 plików, aby obsłużyć powyższe działanie lub zdarzenie, to czasami nadal musimy wywołać backend api korzystanie z usługi, która wydaje się znacznie bardziej skomplikowana i zbędna ...

W innym scenariuszu widzę nawet, że strona używa @ ngrx / store do przechowywania obiektu lub listy obiektów, takich jak dane siatki. , czy to dla jakiegoś rodzaju użycia magazynu w pamięci?

Wracając do pytania, dlaczego używamy @ ngrx / store zamiast usługi rejestracji sklepu tutaj w projekcie Angular? Wiem, że służy do „ZARZĄDZANIA STANEM ”, ale czym dokładnie jest „ZARZĄDZANIE STANEM”? Czy to coś w rodzaju dziennika transakcji i kiedy go potrzebujemy? Dlaczego mielibyśmy tym zarządzać na froncie? Zachęcamy do dzielenia się sugestiami lub doświadczeniami w obszarze @ ngrx / sklepu!

Myślę, że powinieneś przeczytać te dwa posty o sklepie Ngrx:

• Warstwy usług Angular: Redux, RxJs i Ngrx Store - kiedy używać sklepu i dlaczego?
• Sklep Ngrx - przewodnik po architekturze

Jeśli pierwsza z nich wyjaśnia główne problemy rozwiązane przez Ngrx Store, cytuje również to stwierdzenie z React How-To ", które wydaje się odnosić w równym stopniu do oryginalnego Flux, Redux, Ngrx Store lub ogólnie do każdego rozwiązania sklepu":

Dowiesz się, kiedy potrzebujesz Fluxa. Jeśli nie jesteś pewien, czy tego potrzebujesz, nie potrzebujesz tego.

Dla mnie sklep Ngrx rozwiązuje wiele problemów. Na przykład, gdy masz do czynienia z obserwowalnymi i gdy odpowiedzialność za niektóre obserwowalne dane jest dzielona między różne komponenty. W tym przypadku akcje przechowywania i reduktor zapewniają, że modyfikacje danych zawsze będą wykonywane „we właściwy sposób”.

Zapewnia również niezawodne rozwiązanie do buforowania żądań http. Będziesz mógł przechowywać żądania i ich odpowiedzi, abyś mógł sprawdzić, czy żądanie, które składasz, nie ma jeszcze zapisanej odpowiedzi.

Drugi post dotyczy tego, co spowodowało, że takie rozwiązania pojawiły się w świecie React z problemem licznika nieprzeczytanych wiadomości na Facebooku.

Dotyczy Twojego rozwiązania polegającego na przechowywaniu niemożliwych do odzyskania danych w usługach. Działa dobrze, gdy masz do czynienia ze stałymi danymi. Ale kiedy kilka komponentów będzie musiało zaktualizować te dane, prawdopodobnie napotkasz problemy z wykrywaniem zmian i nieprawidłową aktualizacją, które możesz rozwiązać za pomocą:

• wzorzec obserwatora z prywatnym Obiektem publicznym Obserwowalna i następna funkcja
• Sklep Ngrx

Jest też trzecia opcja, np. Posiadanie danych w serwisie i korzystanie z serwisu bezpośrednio w html *ngFor="let item of userService.users". Tak więc, gdy aktualizujesz userService.usersw usłudze po dodaniu lub aktualizacji, akcja jest automatycznie renderowana w formacie HTML, nie ma potrzeby stosowania żadnych obserwacji, zdarzeń ani przechowywania.

Jeśli dane w Twojej aplikacji są używane w wielu składnikach, wymagana jest usługa udostępniania danych. Istnieje wiele sposobów, aby to zrobić.

Umiarkowanie złożona aplikacja będzie ostatecznie wyglądać jak struktura frontendowego zaplecza, z przetwarzaniem danych w usługach, udostępniając dane komponentom za pomocą obserwałów.

W pewnym momencie będziesz musiał napisać jakiś rodzaj API do swoich usług danych, jak pobierać i wysyłać dane, zapytania itp. Wiele reguł, takich jak niezmienność danych i dobrze zdefiniowane pojedyncze ścieżki do modyfikowania danych. Nie inaczej niż w przypadku zaplecza serwera, ale znacznie szybszy i bardziej responsywny niż wywołania interfejsu API.

Twój interfejs API będzie wyglądał jak jedna z wielu bibliotek zarządzania stanem, które już istnieją. Istnieją, aby rozwiązywać trudne problemy. Możesz ich nie potrzebować, jeśli Twoja aplikacja jest prosta.