Redux/ngrx/store architecture: dlaczego nie wysyłać akcji z głupich komponentów?

Question

Buduję aplikację Anglar 2 ngrx/store i staram się zrozumieć najlepsze praktyki.

• Uwielbiam mieć niezmienny stan, który zmienia się tylko na podstawie wysłanych działań, dzięki czemu stan aplikacji jest bardzo przejrzysty i możliwy do debugowania.
• Uwielbiam jednostronny przepływ danych z "inteligentnych" kontenerów, ponieważ pozwala nam to używać rury asynchronicznej do mniejszej kontroli stanu.

Ale nie rozumiem, dlaczego chcielibyśmy "spaprać" wydarzenia od głupich komponentów do inteligentnych komponentów przed wysłaniem akcji do sklepu. Czy jest to jedyny powód, aby mieć elementy, które można ponownie wykorzystać? Wydaje mi się, że większość komponentów nie jest ponownie wykorzystywana, ponieważ nie ma wielu sytuacji, w których chciałbym mieć wszystko identyczne, w tym CSS. Czy są jakieś inne korzyści, których mi brakuje? Z punktu widzenia łatwości konserwacji/czytelności, czy nie jest przyjemniej móc zobaczyć działanie wysłane bezpośrednio w komponencie, w którym odbywa się interakcja?

Answer 1

Całkowicie się z tobą zgadzam i mam takie same wątpliwości.

Oczekuję, że komponent wyśle ​​akcję za pomocą programu rozsyłającego (który dla ngrx/store jest samym magazynem) zamiast przenosić tę logikę do kontenera (rzeczywista aplikacja).

W ten sposób komponent jest odłączony od kontenera, a kontener nie musi wiedzieć o akcjach: będzie tylko słuchał zmiany stanu i przekazywał ewentualne dane.

Z drugiej strony, Introduction to ngrx/store promuje projekt dzięki inteligentniejszemu pojemnikowi, który wiele wie o podstawowych elementach.

Szczerze nie mogę jeszcze zobaczyć zwycięzcę: Po prostu myślę, że akcje wysyłkowe z komponentu jest prostsze, czystsze i bliżej Elm Architecture która była jedną z inspiracji na Redux za.

Answer 2

Nie znalazłem żadnych odniesień dotyczących zdarzeń "bubble up" do najlepszych komponentów w ngrx/example-app. Również w rozmowach Roba nie dostałem tego (mógłbym coś przeoczyć).

Po prostu używam wszystkich ngrx, jak w przykładzie, a teraz wydaje się dobrze. ngrx/store do przechowywania danych, ngrx/effects do akcji łańcuchowych (co mogę uprościć) i "middleware" w obrazie "działań" opisujących wszystko, co możesz zrobić z jedną z części sklepu.

A potem, gdy wydaje się najbardziej wygodne, używam akcji (po prostu upewniając się, że wszystkie akcje użyte w pliku są istotne dla aktualnej klasy).

Answer 3

Jednym z głównych powodów jest ponowne użycie.

Pod względem MVC pomyśl o swoim inteligentnym komponencie jako kontrolerze i głupi komponencie jako o widoku.

Wyobraź sobie głupi komponent, który renderuje formularz edycji dla jednej z twoich jednostek (model). Głupi komponent obsługuje wyświetlanie formularzy i komunikatów sprawdzania poprawności, jednak można ponownie użyć tego komponentu na ekranie dodawania elementów, ekranie encji edycji, a może na przykład w wyskakującym okienku dialogowym w innym miejscu aplikacji. Każdy z tych przypadków użycia wymaga tej samej formy z takim samym sprawdzaniem poprawności, ale najprawdopodobniej wykonasz bardzo różne akcje w "przesłaniu".Inteligentny komponent, który wywołał głupi komponent, jest w każdym przypadku innym inteligentnym komponentem. Podnosząc wydarzenie i przekazując wartości do inteligentnego komponentu, możesz wykonywać bardzo różne akcje, jednocześnie tylko kodując swój "widok".

Answer 4

Po pierwsze, nie jestem ekspertem w kwestii wyłączenia odpowiedzialności.

• czuję, że inteligentne elementy sterujące dumb składników jest rzeczywiście to, co nazywa się wzór mediatora. Korzystanie z tego wzoru zapewnia, że ​​mniej komponentów musi sobie poradzić z store, zwiększając tym samym łączenie wszy.
• Łatwa konserwacja: Jeśli musisz refaktoryzować i zmieniać nazwy akcji, to łatwiej, gdy akcja jest obecna w mniejszej liczbie miejsc.
• Posiadanie centralnego miejsca, które zajmuje się actions, umożliwia szybki przegląd architektury pod numerem. Również zmiana logiki dostępu w trybie hot-swap może być łatwiejsza.
• Jak już wspomniano: ponowne użycie. Możesz dzielić i wykorzystywać głupie komponenty pomiędzy projektami, które mają lub nie mają architektury ngrx.
• Również do ponownego wykorzystania w tym samym projekcie, po prostu przez podłączenie różnych inputs i outputs. Przykład: dropdownComponent może mieć wiele zastosowań, które wymagają różnych wejść i wyjść.