React-Redux: Czy wszystkie stany składników mają być przechowywane w sklepie Redux

Powiedz, że mam prosty przełącznik:

Kiedy klikam przycisk, składnik Kolor zmienia się z czerwonego na niebieski

Mogę osiągnąć ten wynik, robiąc coś takiego.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

reduktor.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

ale to jest cholernie dużo kodu do napisania dla czegoś, co mógłbym osiągnąć w 5 sekund z jQuery, niektórymi klasami i niektórymi css ...

Więc myślę, że tak naprawdę pytam, co ja tu robię źle?

Redux jest przeznaczony głównie dla „stanu aplikacji”. To znaczy wszystko, co jest związane z logiką aplikacji. Widok zbudowany na nim jest odbiciem tego stanu, ale nie musi wyłącznie używać tego kontenera stanu do wszystkiego, co robi.

Wystarczy zadać następujące pytania: Czy ten stan ma znaczenie dla reszty aplikacji? Czy inne części aplikacji będą zachowywać się inaczej w zależności od tego stanu? W wielu drobnych przypadkach tak nie jest. Rozwiń menu: Fakt, że jest otwarty lub zamknięty, prawdopodobnie nie będzie miał wpływu na inne części aplikacji. Więc podłączenie go do twojego sklepu to prawdopodobnie przesada. Z pewnością jest to ważna opcja, ale tak naprawdę nie zapewnia żadnych korzyści. Lepiej jest używać this.statei nazywać to codziennie.

W twoim konkretnym przykładzie, czy kolor tego przycisku jest przełączany, aby wpłynąć na inne części aplikacji? Jeśli jest to jakiś globalny przełącznik włączania / wyłączania dla większej części aplikacji, to zdecydowanie należy do sklepu. Ale jeśli po prostu przełączasz kolor przycisku po kliknięciu przycisku, możesz pozostawić stan koloru zdefiniowany lokalnie. Akcja kliknięcia przycisku może mieć inne efekty, które wymagają wysłania akcji, ale jest to niezależne od prostego pytania, jakiego koloru powinien być.

Ogólnie staraj się, aby stan aplikacji był jak najmniejszy. Nie musisz tam wszystkiego wrzucać . Rób to, kiedy musisz, albo warto coś tam zatrzymać. Lub jeśli ułatwi Ci to życie podczas korzystania z narzędzi deweloperskich. Ale nie przeciążaj zbytnio jego znaczenia.

Redux FAQ: Organizacja
Podaj, że ta część oficjalnego dokumentu redux dobrze odpowiedziała na twoje pytanie.

Używanie stanu komponentu lokalnego jest w porządku . Twoim zadaniem jako programisty jest określenie, jakie stany składają się na Twoją aplikację i gdzie powinny znajdować się poszczególne elementy stanu. Znajdź równowagę, która Ci odpowiada i idź z nią.

Kilka typowych reguł określania, jakie dane powinny zostać umieszczone w Redux:

• Czy inne części aplikacji dbają o te dane?
• Czy musisz mieć możliwość tworzenia dalszych danych pochodnych na podstawie tych oryginalnych danych?
• Czy te same dane są używane do obsługi wielu komponentów?
• Czy przywracanie tego stanu do określonego punktu w czasie ma dla Ciebie wartość (tj. Debugowanie podróży w czasie)?
• Czy chcesz buforować dane (tj. Użyć tego, co jest w stanie, jeśli już tam są, zamiast ponownie o nie poprosić)?

W celu podkreślenia świetnego linku dostarczonego przez @ AR7 i ponieważ ten link został przesunięty jakiś czas temu:

Użyj React, aby uzyskać efemeryczny stan, który nie ma znaczenia dla aplikacji na całym świecie i nie zmienia się w skomplikowany sposób. Na przykład przełącznik w jakimś elemencie interfejsu użytkownika, stan wejścia formularza. Użyj Redux dla stanu, który ma znaczenie globalne lub jest zmutowany w złożony sposób. Na przykład użytkownicy z pamięci podręcznej lub wersja robocza posta.

Czasami będziesz chciał przejść ze stanu Redux do stanu React (gdy przechowywanie czegoś w Redux staje się niewygodne) lub odwrotnie (gdy więcej komponentów musi mieć dostęp do jakiegoś stanu, który był wcześniej lokalny).

Ogólna zasada brzmi: rób wszystko, co jest mniej niezręczne.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

Tak, warto dążyć do przechowywania stanu wszystkich komponentów w Redux . Jeśli to zrobisz, skorzystasz z wielu funkcji Redux, takich jak debugowanie podróży w czasie i powtarzalne raporty o błędach. Jeśli tego nie zrobisz, te funkcje mogą być całkowicie bezużyteczne .

Za każdym razem, gdy nie zapiszesz zmiany stanu składnika w Redux, ta zmiana zostanie całkowicie utracona ze stosu zmian Redux, a interfejs użytkownika aplikacji nie będzie zsynchronizowany ze sklepem. Jeśli to nie jest dla Ciebie ważne, zadaj sobie pytanie, po co w ogóle używać Redux? Bez niej Twoja aplikacja będzie mniej złożona!

Ze względu na wydajność możesz chcieć wrócić do this.setState()czegokolwiek, co spowodowałoby wielokrotne wywołanie wielu działań. Na przykład: przechowywanie stanu pola wejściowego w Redux za każdym razem, gdy użytkownik wpisze klucz, może spowodować niską wydajność. Możesz rozwiązać ten problem, traktując to jak transakcję: gdy akcja użytkownika zostanie „zatwierdzona”, zapisz stan końcowy w Redux.

Twój oryginalny post wspomina o tym, że sposób Redux to „piekielnie dużo kodu do napisania”. Tak, ale można używać abstrakcji dla typowych wzorców, takich jak stan komponentu lokalnego.