Jako uwaga: przeczytałem dokumentację dotyczącą Redux (także Baobab) i sporo zrobiłem z Google'a i testów.
Dlaczego tak mocno sugeruje się, że aplikacja Redux ma tylko jeden sklep?
Rozumiem zalety / wady konfiguracji z jednym sklepem w porównaniu z konfiguracją z wieloma sklepami ( na ten temat istnieje wiele pytań i odpowiedzi ).
IMO, ta decyzja architektoniczna należy do twórców aplikacji na podstawie potrzeb ich projektów. Dlaczego więc jest tak mocno sugerowane Redux, aż do tego stopnia, że brzmi to obowiązkowo ( chociaż nic nie powstrzymuje nas przed tworzeniem wielu sklepów )?
EDYCJA: informacja zwrotna po konwersji do jednego sklepu
Po kilku miesiącach pracy z redux nad tym, co wielu uważa za złożone SPA, mogę powiedzieć, że struktura pojedynczego sklepu była czystą przyjemnością do pracy.
Kilka punktów, które mogą pomóc innym zrozumieć, dlaczego pojedynczy sklep a wiele sklepów jest spornym pytaniem w wielu, wielu przypadkach użycia:
- jest niezawodny : używamy selektorów do przeglądania stanu aplikacji i uzyskiwania informacji kontekstowych. Wiemy, że wszystkie potrzebne dane są w jednym sklepie. Pozwala to uniknąć wszelkich pytań o to, gdzie mogą być problemy ze stanem.
- jest szybki : nasz sklep ma obecnie blisko 100 reduktorów, jeśli nie więcej. Nawet przy tej liczbie tylko garść reduktorów przetwarza dane dla dowolnej wysyłki, pozostałe tylko zwracają poprzedni stan. Argument, że ogromny / złożony sklep ( liczba reduktorów ) jest powolny, jest dość dyskusyjny. Przynajmniej nie widzieliśmy żadnych problemów z wydajnością.
- przyjazny dla debugowania : chociaż jest to najbardziej przekonujący argument, aby używać redux jako całości, dotyczy to również jednego sklepu lub wielu sklepów. Podczas tworzenia aplikacji z pewnością występują błędy stanu ( błędy programisty ), jest to normalne. PITA jest wtedy, gdy błędy te wymagają wielu godzin debugowania. Dzięki jednemu sklepowi ( i redux-loggerowi ) nigdy nie spędziliśmy więcej niż kilka minut na jakimkolwiek problemie ze stanem.
kilka wskazówek
Prawdziwe wyzwanie w budowaniu sklepu redux polega na podjęciu decyzji o jego strukturze . Po pierwsze, ponieważ zmiana struktury w dół drogi to tylko duży ból. Po drugie, ponieważ w dużej mierze determinuje to, w jaki sposób będziesz używać, i zapytania aplikacji o dane dla dowolnego procesu. Istnieje wiele sugestii dotyczących struktury sklepu. W naszym przypadku uznaliśmy za idealne:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}Mamy nadzieję, że ta opinia pomoże innym.
EDYCJA 2 - pomocne narzędzia sklepu
Dla tych z Was, którzy zastanawiają się, jak „łatwo” zarządzać jednym sklepem , który może szybko się skomplikować. Istnieją narzędzia, które pomagają wyodrębnić zależności strukturalne / logikę sklepu.
Istnieje Normalizr, który normalizuje dane na podstawie schematu. Następnie zapewnia interfejs do pracy z danymi i pobierania innych części danych id, podobnie jak Słownik.
Nie znając wówczas Normalizra, zbudowałem coś według tych samych zasad. relational-json przyjmuje schemat i zwraca interfejs oparty na tabeli ( trochę jak baza danych ). Zaletą relational-json jest to, że struktura danych dynamicznie odwołuje się do innych części danych ( zasadniczo można przesuwać dane w dowolnym kierunku, podobnie jak normalne obiekty JS ). Nie jest tak dojrzały jak Normalizr, ale od kilku miesięcy z powodzeniem go używam w produkcji.