Dlaczego warto używać Redux nad Facebook Flux?

W Quora ktoś mówi :

Po pierwsze, jest całkowicie możliwe pisanie aplikacji z Reactem bez / Align = "left" /

Również ten wizualny schemat który stworzyłem pokazuje Szybki podgląd obu, prawdopodobnie szybką odpowiedź dla osób, które nie chcą czytać całego wyjaśnienia:

Ale jeśli nadal chcesz wiedzieć więcej, Czytaj dalej.

Uważam, że powinieneś zacząć od czystego Reacta, a następnie nauczyć się Redux i Flux. Po tym, jak będziesz miał prawdziwe doświadczenie z Reactem, zobaczysz czy Redux jest pomocny dla Ciebie, czy nie.

Może poczujesz, że Redux jest właśnie dla Twojej aplikacji, a może ty dowiesz się, że Redux próbuje rozwiązać problem, którego nie jesteś naprawdę doświadcza.

Jeśli zaczniesz bezpośrednio z Redux, możesz skończyć z over-engineered kod, kod trudniejszy do utrzymania i z jeszcze większą ilością błędów i niż bez Redux.

Z Redux docs :

Motywacja
ponieważ wymagania dla aplikacji jednostronicowych JavaScript stają się coraz bardziej skomplikowane, nasze kod musi zarządzać większą liczbą Stanów niż kiedykolwiek wcześniej. Stan ten może obejmować odpowiedzi serwera i danych buforowanych, a także lokalnie utworzonych danych, które nie został jeszcze dodany do serwera. Zwiększa się również stan UI w złożoności, ponieważ musimy zarządzać aktywnymi trasami, wybrane zakładki, Spinnery, sterowanie paginacją i tak dalej.

Zarządzanie tym ciągle zmieniającym się stanem jest trudne. Jeśli model może zaktualizować inny model, a następnie Widok może zaktualizować model, który aktualizuje inny model, a to z kolei może spowodować aktualizację innego widoku. W niektórych punkt, nie rozumiesz już, co dzieje się w Twojej aplikacji, jak masz stracił kontrolę nad tym, kiedy, dlaczego i jak swojego stanu. Gdy system jest nieprzezroczysta i niedeterministyczna, trudno odtworzyć błędy lub dodać nowe funkcje.

Jakby to nie było wystarczająco złe, rozważ nowe wymagania stają się wspólne w rozwoju produktu front-end. Jako deweloperzy jesteśmy oczekuje obsługi aktualizacji, renderowania po stronie serwera, pobierania dane przed wykonaniem przejścia trasy i tak dalej. Znajdujemy siebie próba zarządzania złożonością, z którą nigdy nie mieliśmy do czynienia wcześniej i nieuchronnie zadajemy pytanie: czy nadszedł czas, aby się poddać? Na odpowiedź brzmi nie.

Ta złożoność jest trudna do opanowania, ponieważ mieszamy dwa pojęcia które są bardzo trudno rozumować umysłowi ludzkiemu o: mutacji i asynchroniczność. Nazywam je Mentos i Cola. Oba mogą być świetne, gdy rozdzieleni, ale razem tworzą bałagan. Biblioteki takie jak React spróbuj rozwiązać ten problem w warstwie widoku, usuwając oba asynchroniczna i bezpośrednia manipulacja DOM. Jednak zarządzanie stanem Twoje dane są pozostawione do ciebie. Tu pojawia się Redux.

Podążając śladami Flux, CQRS i Event Sourcing, Redux próby dokonania mutacje stanu przewidywalne przez narzucanie pewnych ograniczenia dotyczące sposobu i czasu aktualizacji. Ograniczenia te znajdują odzwierciedlenie w trzech zasadach Redux.

Również z Redux docs :

Podstawowe pojęcia
Sam Redux jest bardzo prosty.

Wyobraź sobie, że stan Twojej aplikacji jest opisany jako zwykły obiekt. Na przykład, stan aplikacji todo może wyglądać tak:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

Ten obiekt jest jak "model" z tym wyjątkiem, że nie ma seterów. To jest tak, że różne części kodu nie mogą zmienić stanu arbitralnie, powodując trudne do odtworzenia błędy.

Aby zmienić coś w stanie, musisz wysłać akcję. Na action to zwykły obiekt JavaScript (zauważ, że nie wprowadzamy żadnych Magia?) to opisuje, co się stało. Oto kilka przykładowych działań:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

Wymuszenie, że każda zmiana jest opisana jako działanie pozwala nam na jasne zrozumienie tego, co się dzieje w aplikacji. Jeśli coś zmienił się, wiemy dlaczego się zmienił. Działania są jak bułka Tartaczna tego, co stało się. Na koniec, aby połączyć stan i działania, piszemy funkcja zwana reduktorem. Znowu nie ma w tym nic magicznego - to tylko funkcja, która przyjmuje stan i akcję jako argumenty i zwraca Następny stan aplikacji. Trudno byłoby napisać taką funkcję dla duża aplikacja, więc piszemy mniejsze funkcje zarządzające częściami stanu:

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

I piszemy kolejny reduktor, który zarządza całkowitym stanem naszego app wywołując te dwa reduktory dla odpowiednich kluczy stanu:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

To jest w zasadzie cała idea Redux. Zauważ, że nie użyliśmy wszystkie API Redux. Jest wyposażony w kilka narzędzi, aby to ułatwić wzorca, ale główną ideą jest to, że opisujesz swój stan aktualizowane w czasie w odpowiedzi na obiekty akcji, a 90% kodu piszesz to po prostu zwykły JavaScript, bez użycia samego Redux, jego APIs, lub każda Magia.

Najlepiej zacząć od przeczytania tego postu dana Abramova, gdzie omawia różne implementacje Flux i ich kompromisy w czasie, gdy pisał redux: The Evolution of Flux Framework

Po drugie strona z motywacjami, do której linkujesz, nie omawia tak naprawdę motywacji Redux, jak motywacji stojących za Flux (i reagowaniem). Trzy zasady {[2] } są bardziej specyficzne dla Redux, choć nadal nie zajmuje się różnicami w implementacji od standardowa Architektura Flux.

Zasadniczo Flux ma wiele magazynów, które obliczają zmiany stanu w odpowiedzi na interakcje UI/API z komponentami i transmitują te zmiany jako zdarzenia, które komponenty mogą subskrybować. W Redux jest tylko jeden sklep, do którego subskrybuje każdy komponent. IMO wydaje się, że Redux jeszcze bardziej upraszcza i unifikuje przepływ danych, unifikując (lub zmniejszając, jak powiedziałby Redux) przepływ danych z powrotem do komponentów - podczas gdy Flux koncentruje się na ujednolicenie drugiej strony przepływu danych - widok do modelu.

Jestem początkującym użytkownikiem i zaimplementowałem średnio-dużą aplikację jednostronicową przy użyciu biblioteki Facebook Flux.

Ponieważ jestem trochę spóźniony na rozmowę, zaznaczę tylko, że pomimo moich największych nadziei, Facebook wydaje się uważać ich implementację Flux za dowód koncepcji i nigdy nie otrzymał uwagi, na którą zasługuje.

Zachęcam do zabawy, ponieważ eksponuje więcej wewnętrznego działania architektury Flux, która jest dość edukacyjna, ale jednocześnie czas nie zapewnia wielu korzyści, jakie zapewniają biblioteki takie jak Redux (które nie są tak ważne dla małych projektów, ale stają się bardzo cenne dla większych).

Zdecydowaliśmy, że idąc dalej przenosimy się na Redux i proponuję zrobić to samo;)

Oto proste wyjaśnienie Redux nad Flux. Redux nie posiada dispatcher.It opiera się na czystych funkcjach zwanych reduktorami. Nie potrzebuje dyspozytora. Każda akcja jest obsługiwana przez jeden lub więcej reduktorów, aby zaktualizować pojedynczy magazyn. Ponieważ dane są niezmienne, reduktory zwracają nowy zaktualizowany stan, który aktualizuje Sklep

Więcej informacji http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html

Pracowałem dość długo z Fluxem, a teraz dość długo z Reduxem. Jak zauważył Dan, obie architektury nie różnią się tak bardzo. Chodzi o to, że Redux sprawia, że rzeczy prostsze i czystsze. Uczy cię kilku rzeczy na topie. Jak na przykład Flux jest doskonałym przykładem jednokierunkowego przepływu danych. Rozdzielenie problemów, w których mamy dane, ich manipulacje i odseparowane warstwy widoku. W Redux mamy te same rzeczy, ale uczymy się również o niezmienności i czystości funkcje.

Poza argumentami technicznymi opisanymi w poprzednich odpowiedziach, IMHO dwa ważne powody to:

• Narzędzia: Redux dev tool jest niesamowite narzędzie, sprawia, że programista / debugowania doświadczenie wybuch (wehikuł czasu, możliwość eksportu sesji użytkownika i odtworzyć go w lokalnym środowisku...).

• Stack overflow friendly: Redux uzyskał ponad 51000 wyników na stackoverflow, flux 9000.