Niedawno odkryłem Redux . Wszystko wygląda dobrze. Czy są jakieś wady, problemy lub kompromisy w korzystaniu z Redux nad Flux? Dzięki

Redux autor tutaj!

Chciałbym powiedzieć, że będziesz korzystał z następujących kompromisów:

• Musisz nauczyć się unikać mutacji. Flux nie ma nic wspólnego z mutowaniem danych, ale Redux nie lubi mutacji, a wiele pakietów komplementarnych do Redux zakłada, że ​​nigdy nie mutujesz stanu. Możesz to wymusić dzięki pakietom przeznaczonym tylko dla programistów, takim jak redux-immutable-state-niezmiennik , użyj Immutable.js lub zaufaj sobie i swojemu zespołowi, że piszemy niezmutowany kod, ale musisz o tym wiedzieć, a to musi być być świadomą decyzją zaakceptowaną przez twój zespół.

• Musisz starannie wybrać swoje paczki. Podczas gdy Flux wyraźnie nie próbuje rozwiązać „pobliskich” problemów, takich jak cofanie / ponawianie , trwałość lub formularze , Redux ma punkty rozszerzeń, takie jak oprogramowanie pośrednie i ulepszenia sklepu, i stworzył młody, ale bogaty ekosystem . Oznacza to, że większość pakietów jest nowymi pomysłami i nie otrzymała jeszcze masy krytycznej użytkowania. Być może będziesz polegać na czymś, co będzie wyraźnie złym pomysłem kilka miesięcy później, ale na razie trudno powiedzieć.

• Nie będziesz jeszcze mieć przyjemnej integracji Flow. Flux pozwala obecnie wykonywać bardzo imponujące testy statyczne, których Redux jeszcze nie obsługuje . Dotrzemy tam, ale zajmie to trochę czasu.

Myślę, że pierwszy jest największą przeszkodą dla początkujących, drugi może być problemem dla nadmiernie entuzjastycznych wczesnych użytkowników, a trzeci to moja osobista wkurzona robota. Poza tym nie sądzę, że używanie Redux ma jakieś wady, których Flux unika, a niektórzy twierdzą, że ma nawet pewne zalety w porównaniu do Fluxa.

Zobacz także moją odpowiedź na temat korzystania z Redux .

Zarówno Redux, jak i Flux wymagają znacznej ilości kodu typu „płyta podstawowa”, aby pokryć wiele popularnych wzorców, szczególnie tych, które wymagają asynchronicznego pobierania danych. Dokumentacja Redux zawiera już kilka przykładów redukcji płyty kotłowej: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Możesz uzyskać wszystko, czego potrzebujesz, z biblioteki Flux, takiej jak Alt lub Fluxxor, ale Redux woli wolność od funkcji. Może to być wadą dla niektórych programistów, ponieważ Redux przyjmuje pewne założenia dotyczące twojego stanu, które można niechcący zignorować.

Jedynym sposobem, aby naprawdę odpowiedzieć na twoje pytanie, jest wypróbowanie Redux, jeśli możesz, być może w osobistym projekcie. Redux powstał z powodu potrzeby lepszego doświadczenia programistów i jest tendencyjny do programowania funkcjonalnego. Jeśli nie znasz koncepcji funkcjonalnych, takich jak reduktory i skład funkcji, możesz zostać spowolniony, ale tylko nieznacznie. Zaletą zastosowania tych pomysłów w przepływie danych jest łatwiejsze testowanie i przewidywalność.

Oświadczenie: migrowałem z Flummox (popularna implementacja Flux) do Redux, a wady znacznie przewyższają wszelkie wady. W moim kodzie wolę znacznie mniej magii. Mniej magii kosztuje trochę więcej płyty grzewczej, ale to bardzo niewielka cena do zapłacenia.

Flux i Redux . . .

Redux nie jest czystą implementacją Fluxa, ale zdecydowanie jest zainspirowany Fluxem. Największą różnicą jest to, że używa pojedynczego sklepu, który otacza obiekt stanu zawierający cały stan dla aplikacji. Zamiast tworzyć sklepy, tak jak we Fluxie, napiszesz funkcje reduktora, które zmienią stan pojedynczego obiektu. Ten obiekt reprezentuje cały stan w Twojej aplikacji. W Redux uzyskasz bieżącą akcję i stan, i zwrócisz nowy stan. Oznacza to, że działania są sekwencyjne, a stan jest niezmienny. To doprowadziło mnie do najbardziej oczywistego oszustwa w Redux (moim zdaniem).

Dlaczego niezmienność?

Powodów tego jest kilka:
1. Spójność - stan sklepu jest zawsze zmieniany przez reduktor, więc łatwo jest śledzić, kto co zmienia.
2. Wydajność - ponieważ jest niezmienna, Redux musi tylko sprawdzić, czy poprzedni stan! == aktualny stan, a jeśli tak, to renderować. Nie trzeba za każdym razem zapętlać stanu, aby określić renderowanie.
3. Debugowanie - nowe niesamowite koncepcje, takie jak debugowanie w czasie i przeładowywanie na gorąco .

AKTUALIZACJA: jeśli to nie było wystarczająco przekonujące, obejrzyj doskonałe rozmowy Lee Byrona na temat niezmiennych interfejsów użytkownika .

Redux wymaga dyscypliny programistów poprzez bazę kodu / biblioteki, aby utrzymać ten pomysł. Musisz upewnić się, że wybierasz biblioteki i piszesz kod w sposób niezmienny.

Jeśli chcesz dowiedzieć się więcej na temat różnych implementacji koncepcji Flux (i tego, co najlepiej pasuje do twoich potrzeb), sprawdź to przydatne porównanie.

Powiedziawszy to, muszę przyznać, że Redux jest miejscem, w którym zmierza przyszły rozwój JS (jeśli chodzi o pisanie tych wierszy).

Jedną z największych zalet korzystania z Redux w porównaniu z innymi alternatywami Flux jest jego zdolność do zmiany orientacji myślenia na bardziej funkcjonalne. Kiedy zrozumiesz, w jaki sposób wszystkie przewody się łączą, zdajesz sobie sprawę z jego oszałamiającej elegancji i prostoty projektowania i nigdy nie możesz wrócić.

Wolę używać Redux ponieważ wykorzystuje jeden sklep, który sprawia, że zarządzanie stan znacznie łatwiej porównać do Flux również DevTools Redux to naprawdę pomocne narzędzia, które pozwalają zobaczyć, co robisz ze swoim stanie z kilku przydatnych danych i to naprawdę inline z React narzędzia rozwijające się.

Również Redux ma większą elastyczność korzystając z innych popularnych ram jak kątowych . W każdym razie zobaczmy, jak Redux przedstawia się jako framework.

Redux ma Trzy Zasady, które mogą bardzo dobrze wprowadzić Redux i są główną różnicą między Redux i Flux.

Jedno źródło prawdy

Stan całej aplikacji jest przechowywany w drzewie obiektów w jednym magazynie.

Ułatwia to tworzenie uniwersalnych aplikacji, ponieważ stan z serwera można przekształcić do postaci szeregowej i uwodnić do klienta bez dodatkowego kodowania. Jedno drzewo stanów ułatwia także debugowanie lub kontrolę aplikacji; umożliwia także utrzymanie stanu aplikacji w fazie rozwoju, co przyspiesza cykl programowania. Niektóre funkcje, które tradycyjnie były trudne do wdrożenia - na przykład Cofnij / Ponów - mogą nagle stać się trywialne, jeśli cały stan jest przechowywany w jednym drzewie.

console.log(store.getState())

/* Prints
{
  visibilityFilter: 'SHOW_ALL',
  todos: [
    {
      text: 'Consider using Redux',
      completed: true,
    },
    {
      text: 'Keep all state in a single tree',
      completed: false
    }
  ]
}
*/

Stan jest tylko do odczytu

Jedynym sposobem na zmianę stanu jest wysłanie akcji, obiektu opisującego co się stało.

Zapewnia to, że ani widoki, ani wywołania zwrotne sieci nigdy nie będą zapisywać bezpośrednio do stanu. Zamiast tego wyrażają zamiar przekształcenia państwa. Ponieważ wszystkie zmiany są scentralizowane i następują jeden po drugim w ścisłej kolejności, nie ma subtelnych warunków wyścigowych, na które trzeba uważać. Ponieważ akcje są zwykłymi obiektami, mogą być rejestrowane, serializowane, przechowywane, a następnie odtwarzane w celu debugowania lub testowania.

store.dispatch({
  type: 'COMPLETE_TODO',
  index: 1
})

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',
  filter: 'SHOW_COMPLETED'
})

Zmiany są dokonywane za pomocą czystych funkcji

Aby określić, w jaki sposób drzewo stanu jest przekształcane przez działania, piszesz czyste reduktory.

Reduktory to po prostu funkcje, które przyjmują poprzedni stan i akcję i zwracają następny stan. Pamiętaj, aby zwrócić nowe obiekty stanu, zamiast mutować poprzedni stan. Możesz zacząć od pojedynczego reduktora, a wraz z rozwojem aplikacji, podziel go na mniejsze reduktory, które zarządzają określonymi częściami drzewa stanu. Ponieważ reduktory to tylko funkcje, możesz kontrolować kolejność ich wywoływania, przekazywać dodatkowe dane, a nawet tworzyć reduktory wielokrotnego użytku do typowych zadań, takich jak paginacja.

function visibilityFilter(state = 'SHOW_ALL', action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo, index) => {
        if (index === action.index) {
          return Object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)

Aby uzyskać więcej informacji, odwiedź tutaj

Redux wymaga dyscypliny w zakresie niezmienności. Mogę polecić ng-freeze, aby poinformować cię o każdej przypadkowej mutacji stanu.

O ile mi wiadomo, redux jest inspirowany przez flux. flux jest architekturą podobną do MVC (kontroler widoku modelu). Facebook wprowadza strumień ze względu na problem ze skalowalnością podczas korzystania z MVC. więc flux nie jest implementacją, to tylko koncepcja. W rzeczywistości redux jest implementacją strumienia.