Czym jest react redux i jak wygląda tworzenie aplikacji redux w 2021 roku?

Chcę zaprosić Cię w podróż przez react-redux. Zobaczysz:

• Jakie podejście do zarządzania stanami w aplikacjach reactowych jest ważne?
• Czym jest redux i dlaczego warto go używać?
• Czym są architektura Flux i event sourcing?
• Jaka jest architektura typowej aplikacji redux?
• Jak zarządzać efektami ubocznymi w aplikacji redux?
• Jakie są alternatywy dla oprogramowania pośredniczącego redux-thunk?
• Jakie hooks oferuje react-redux?
• Jakie jest najlepsze podejście do testowania aplikacji redux?

Czym jest state management?

Zarządzanie stanem ma na celu umożliwienie wymiany i wykorzystania danych między różnymi sektorami. Tworzy konkretną strukturę danych, która reprezentuje stan aplikacji do odczytu.

Większość frameworków, w tym React, posiada sposób na kontrolowanie stanu przez komponenty. Jest to również pomocne w przypadku aplikacji z kilkoma komponentami, ale zarządzanie stanem między komponentami może szybko stać się zadaniem.

Dlatego potrzebne są narzędzia do zarządzania stanem, które ułatwiają jego utrzymanie. Oczywiste jest, że zarządzanie stanem staje się trudne, ponieważ aplikacja jest skomplikowana, więc potrzebujesz narzędzia do zarządzania stanem, takiego jak Redux.

Redux jest przewidywalnym kontenerem stanu dla aplikacji JavaScript i oferuje scentralizowany sposób zarządzania stanem. Korzystając z frameworka takiego jak React, możemy powiedzieć niektórym częściom kodu, aby pokazywały tylko określone wartości stanu.

Aktualizacje właściwości stanu zostaną automatycznie przesłane do interfejsu użytkownika (jeśli są tam renderowane). W sumie stan odnosi się do stanu czegoś w danym momencie, takiego jak to, czy modal jest otwarty, czy nie, które dane powinny być widoczne, który widok jest aktywny i tak dalej.

Dlaczego warto używać redux?

Redux to wzorzec i biblioteka do zarządzania i aktualizowania stanu aplikacji za pomocą zdarzeń zwanych akcjami, które realizują to zadanie poprzez definiowanie akcji wysyłanych do reduktorów. Wszystkie akcje w aplikacji mogą mieć typ i payload.

Reducer akceptuje akcję i zmienia stan w zależności od typu akcji odbiorcy i ładunku. Reduktory są czystymi funkcjami i dlatego są przewidywalne.

Prosta funkcja zwraca te same dane wyjściowe dla tych samych danych. Oprócz komunikacji z naszą aplikacją, możemy subskrybować aktualizacje danych. Jest to proste, ale eleganckie rozwiązanie ułatwiające zarządzanie stanem dla małych i dużych aplikacji.

Kiedy używać Redux

Redux API pozwala na utrzymanie stanu aplikacji i utrzymanie jej bardziej przewidywalnej. Pomysł dodawania kodu może wydawać się nieco uciążliwy i sprawiać, że skomplikowane rzeczy wydają się nieco przytłaczające, ale może to zależeć od decyzji podejmowanych przez architekturę. Jeśli nadal nie masz pewności, kto ich potrzebuje, to nie potrzebujesz. Zwykły scenariusz zaczyna się, gdy aplikacja firmy rozrasta się do poziomu, w którym utrzymanie stanu aplikacji staje się kłopotliwe. Starasz się, aby zarządzanie aplikacją użytkownika było proste. Korzyści te wiążą się z kompromisami i ograniczeniami, ale wszystkie te kompromisy wiążą się z ograniczeniami i kompromisami, w tym z dodaniem standardowego kodu.

Dlaczego muszę używać React-Redux?

React Redux to oficjalna biblioteka interfejsu Redux dla Reacta. Jeśli używasz Redux z jakimkolwiek frameworkiem UI, zazwyczaj będziesz używać biblioteki z własną wewnętrzną biblioteką „wiążącą”, aby połączyć Redux z frameworkiem UI. Redux to samodzielna biblioteka używana z dowolną warstwą interfejsu użytkownika lub frameworkiem, w tym React Angular Vue Ember i Vanilla JS.

Architektura Redux

Przyjrzyjmy się architekturze react redux i temu, co można znaleźć w typowej aplikacji redux.

Flux

React redux implementuje architekturę Flux (zaproponowaną przez Facebooka). Podstawową zasadą tej architektury jest to, że dane przepływają w jednym kierunku, a stan redux może być zmieniany tylko w jednym miejscu.

Inną koncepcją Flux jest oddzielenie zapisu danych od ich odczytu. Jest on oparty na wzorcu projektowymCommand Query Responsibility Segregation (CQRS).

Ta separacja jest dobra, ponieważ zazwyczaj w aplikacjach odczyt danych jest częstszy niż ich zapis, więc dobrze jest je rozdzielić i skalować, rozwijać i utrzymywać osobno. Oczywiście czasami korzystanie z CQRS nie ma sensu, ale zależy to od wymagań projektu (jak zawsze)

Architektura Flux obejmuje trzy główne obszary:

• view – to, co widzisz i miejsce, w którym możesz wysyłać akcje, które mogą zmieniać dane w sklepie
• dispatcher- odbiera akcje i przekazuje je do sklepów
• store – przechowuje informacje

Tak więc Redux implementuje architekturę Flux na swój sposób i należy pamiętać, że inne narzędzia również implementują Flux, ale w nieco inny sposób. Rzuć okiem na MobXna przykład.

Pozyskiwanie wydarzeń i podróżowanie w czasie.

Kolejną ideą (wzorcem, architekturą), którą implementuje react redux jest event sourcing. Ten wzorzec jest bardziej znany po stronie backendu. Event sourcing na frontendzie w aplikacjach redux oznacza, że stan odczytywany przez widok nie jest źródłem danych.

Stan redux i dane są tworzone przez zdarzenia (akcje w architekturze react redux – więcej informacji poniżej). Zazwyczaj masz domyślny stan sklepu i zmieniasz ten stan, wysyłając akcje.

Dzięki temu można budować stan tego, czego się chce, uruchamiając określone akcje. Wyobraźmy sobie, że tester znajduje błąd w aplikacji i odtwarza go w środowisku lokalnym. Konieczne może być odtworzenie historii działań.

Co więcej, możesz podróżować w czasie, wykonując i wycofując określone działania i widząc unikalny stan dla każdego z nich.

Redux ma globalny sklep i przenosi stany komponentu do jednego centralnego obszaru. Wyraźne miejsce, w którym przechowujemy stan, nazywane jest sklepem.

Zapewnia to również dodatkowy sposób na sprawdzenie, jak w danym okresie zmienia się stan aplikacji. Store jest niezmienny, co oznacza, że nie można go bezpośrednio modyfikować. Można go sklonować i zastąpić zaktualizowanymi właściwościami. To klonowanie daje nam widok naszej aplikacji przydatny do celów debugowania, szczególnie w kontekście zmiany stanu konkretnej aplikacji.

Redux Reducers

Reducer to tylko czysta funkcja, która przyjmuje dwa argumenty i zwraca bieżący stan aplikacji.

Pierwszy argument to aktualny stan, a drugi to akcja, która zmodyfikuje ten stan. Funkcja Reducer zwraca nowy stan na podstawie podanego bieżącego stanu i akcji.

Spójrz na przykładowy reduktor:

export function CarsReducer(state, action) {
    switch(action.type) {
        case 'ADD_CAR': {
            return {
                messages: [
                    ...state.cars,
                    action.car
                ]
            };
        }

        case 'REMOVE_CAR': {
            const indexToToRemove = state.cars.indexOf(action.car);

            if (indexToToRemove >= 0) {
                return {
                    cars: [
                        ...state.cars.splice(indexToToRemove, indexToToRemove)
                    ]
                }
            }

            return state;
        }
        
        default: {
            return state;
        }
    }
}

CarsReducer może obsługiwać dwie akcje: ADD_CAR i REMOVE_CAR . Przyjrzyjmy się, jakie akcje są dostępne w Redux.

Działania Redux

Akcje w redux są obiektami JavaScript zawierającymi dwie cechy zwane typem i ładunkiem. Akcje te będą używane jako argumenty w metodzie API, która wywołuje wysyłkę Redux, gdy element wymaga wysyłki. Aby „wywołać” tę akcję, musimy użyć reduktora w naszym sklepie, aby zaktualizować nasz stan. Następnie używamy tej funkcji do utworzenia nowego stanu sklepu, aby wyświetlić podgląd wyglądu aplikacji po wysłaniu akcji.

Spójrz na przykładowy kreator akcji:

const addCar = car => {
    return {
        type: 'ADD_CAR',
        car
    }
}

Inną konwencją jest wysyłanie obiektu samochodu jako pola ładunku:

const addCar = car => {
    return {
        type: 'ADD_CAR',
        payload: {
            car
        }
    }
}

Obie wersje są dobre. To tylko konwencje. Wolę ten pierwszy.

Funkcje te nazywane są kreatorami akcji, ponieważ zwracają zwykły obiekt JavaScript (obiekt akcji), który można wysłać do sklepu.

Redux i wydajność

Pod względem wydajności w Reakcie, re-rendery są czymś, co ma największy wpływ na wydajność. Gdy używasz Reactowego sposobu obsługi stanu, na przykład haków lub nawet komponentów klas z prywatnym stanem, ponowne renderowanie jest konieczne, gdy stan zostanie zmieniony.

Kiedy integrujesz redux z react, stan jest przechowywany poza react. Oznacza to, że komponenty react odczytują dane z redux store, a w niektórych przypadkach ponowne renderowanie może być zbędne. To jest jak magia, ale redux może zapobiec nadmiarowym ponownym renderom OOTB.

Porównując wydajność redux z React Contexts, różnica jest ogromna. Gdy masz znaczący Kontekst z dużymi obiektami danych i nastąpi zmiana w tym Kontekście, wszyscy subskrybenci Kontekstu (w zasadzie dzieci) zostaną ponownie wyrenderowani.

Oczywiście można zredukować zbędne ponowne renderowania za pomocą haków useCallback lub useMemo, ale trzeba o to zadbać samemu i napisać dodatkowy kod.

Kiedy używasz Redux i wysyłasz jakąś akcję za pomocą haka useDispatch, tylko komponenty, które odczytują zmienione dane, będą renderowane.

To robi różnicę. Oczywiście nie oznacza to, że konteksty React są złe, a redux jest doskonały. Można efektywnie zarządzać stanem na oba sposoby, a wydajność zazwyczaj zależy od implementacji (i jakości).

Oznacza to, że redux może pomóc w zwiększeniu wydajności i należy wziąć to pod uwagę podczas projektowania zarządzania stanem w aplikacji.

Współpracujący interfejs użytkownika

Inną kwestią związaną z wydajnością są aplikacje działające w czasie rzeczywistym. Na przykład dokumenty Google. Można tam edytować dokumenty z innymi użytkownikami w czasie rzeczywistym. W takim przypadku architektura Redux oparta na zdarzeniach jest lepsza, ponieważ łatwiej jest wysyłać tylko zdarzenia między użytkownikami niż wysyłać wszystkie dane dokumentu i obsługiwać zmiany.

Korzystanie z redux zależy więc od typu projektu.

Możesz również zapytać, czy Redux może mieć destrukcyjny wpływ na wydajność aplikacji reactowej? Czasami – tak, ale zazwyczaj nie z powodu redux, ale z powodu niewłaściwego projektu aplikacji.

Stan React redux znajduje się poza Reactem, więc kiedy projektujesz i tworzysz aplikację redux, musisz zdecydować, które dane powinny być częścią magazynu redux, a które prywatnym stanem komponentów. Dobry projekt zarządzania stanem może pomóc uniknąć problemów z wydajnością.

Efekty uboczne

Niektóre działania mogą mieć skutki uboczne. Na przykład po dodaniu produktu do koszyka należy wyświetlić powiadomienie. Z drugiej strony, może zaistnieć potrzeba pracy z danymi asynchronicznymi. Mam na myśli wysłanie żądania danych przed akcją redux lub po niej.

Możesz zarządzać efektami ubocznymi w komponencie react, ale nie jest to dobry pomysł, ponieważ akcja użytkownika, lub ogólnie mówiąc operacja, jest podzielona na dwie części

1. pure – akcja redux – obsługiwana przez reduktor
2. nieczysty – efekt uboczny – kontrolowany przez składnik reagujący

Lepszym rozwiązaniem jest dodanie jednego wspólnego typu miejsca w aplikacji react, w którym można obsługiwać operacje. To miejsce nazywa się: redux middleware.

Oprogramowanie pośredniczące Redux

Oprogramowanie pośredniczące Redux to blok konstrukcyjny, który pozwala hermetyzować wysyłanie akcji redux i zarządzać efektami ubocznymi, danymi asynchronicznymi w jednym miejscu.

Istnieją trzy rodzaje oprogramowania pośredniczącego redux:

1. Thunks (redux-thunk)
2. Sagi (redux-saga)
3. Obserwowalne (redux-observable)

Jeśli tworzysz aplikacje redux, powinieneś wybrać jedno z oprogramowania pośredniczącego, a następnie Redux i oprogramowanie pośredniczące są odpowiedzialne za zarządzanie stanem, a komponenty nie muszą obsługiwać efektów ubocznych. Dlatego są bardziej czytelne i powierzchowne, ponieważ wyświetlają tylko dane.

Zagłębmy się w każdy typ oprogramowania pośredniego redux.

Redux Thunk

Redux-thunks są najprostsze do zrozumienia, więc zacznijmy od nich! Thunks to funkcja, która może wysłać dowolną akcję redux bezpośrednio do sklepu redux.

Co więcej, można wysyłać wiele akcji w jednym thunku i dodawać dodatkową logikę wysyłania, dzięki czemu można wysyłać akcje warunkowo lub w pętli. Ponadto, thunk może wywoływać inne thunki, więc cokolwiek potrzebujesz, wszystko to jest w jednym miejscu.

Istotną zaletą thunków jest to, że komponenty nie wiedzą nic o thunku, który wywołują. Wszystkie zależności i logika znajdują się wewnątrz thunk’ów, a komponenty nazywane są tylko thunk’ami. Cała magia jest w środku.

Spójrz na przykład thunk:

// redux action
function setUser(userData) {
    return {
        type: 'SET_USER',
        userData
    }
}

// redux action
function setError(errorMessage) {
    return {
        type: 'SET_ERROR',
        errorMessage
    }
}

// The thunk 
function fetchUserData(userId) {
    return function (dispatch) {
        return fetch(`https://my-api.com/user/${userId}`).then(
            data => dispatch(setUser(data)),
            error => dispatch(setError(`Something went wrong... ${error}`))
        )
    }
}

W powyższym kodzie można zobaczyć dwie akcje redux: setUser, setError i thunk o nazwie fetchUserData. Ten thunk otrzymuje userId jako parametr i wywołuje API za pomocą fetch, a następnie wysyła akcję setUser lub hak setError, jeśli API zwróci błąd.

Spójrzmy na inny przykład z większą logiką:

function fetchUserB2Bdata() {
    return function (dispatch, getState) {
        const user = getState().user;

        if (!user) {
            return dispatch(setError('User is not authenticated.'))
        }

        if (!user.isB2Buser) {
            return dispatch(setError('User is not a B2B user.'))
        }

        return fetch(`https://my-api.com/user/b2b/${user.id}`).then(
            data => dispatch(setUserB2Bdata(data)),
            error => dispatch(setError(`Something went wrong... ${error}`))
        )
    }
}

Jak widać, istnieje funkcja getState, która pozwala uzyskać aktualny stan i zrobić to, czego potrzebujesz w zależności od niego.

Te przykłady są elementarne, a chciałem pokazać (o czym piszę od jakiegoś czasu) zalety korzystania z thunków: obsługa danych asynchronicznych, enkapsulacja akcji z efektami ubocznymi i dane asynchroniczne.

Sagi (redux-saga)

Przyjrzyjmy się drugiemu typowi oprogramowania pośredniczącego redux. Na stronie głównej redux-saga można przeczytać, że jest to „intuicyjny menedżer efektów ubocznych Redux”. Sprawdźmy, czy to prawda! 🙂

Oto przykładowy fragment kodu, który wykorzystuje redux-saga:

import { call, put, takeEvery } from 'redux-saga/effects'
import Api from '...'

// Worker saga will be fired on REQUEST_USER actions
function* fetchUserData(action) {
    try {
        const userData = yield call(Api.fetchUser, action.payload.userId);
        yield put({type: "SET_USER", userData});
    } catch (error) {
        yield put({type: "SET_ERROR", errorMessage: error});
    }
}

// Starts fetchUser on each dispatched REQUEST_USER action
function* mySaga() {
    yield takeEvery("REQUEST_USER", fetchUserData);
}

To intuicyjne, prawda?

Mam nadzieję, że zgodzisz się ze mną, że na pierwszy rzut oka wygląda to bardziej skomplikowanie niż redux-thunk. Wyjaśnijmy to trochę.

Koncepcja redux-saga jest podobna do wzorca projektowego saga. Każda saga jest niezależną logiką, która jest uruchamiana, gdy wysyłane są określone akcje.

W powyższym przykładzie istnieje saga fetchUserData, która jest uruchamiana przy każdej akcji REQEST_USER redux.

Funkcja takeEvery jest efektem redux-saga. Istnieje również efekt takeLatest, który jest uruchamiany przy ostatniej określonej akcji redux.

Jest więcej efektów, więc potrzebujesz czasu, aby zrozumieć API redux-saga. Co więcej, redux-saga wykorzystuje generatory JavaScript, które działają wydajnie, ale wymagają też więcej uwagi, aby je zrozumieć.

Epics (redux-observable)

Ostatnim typem oprogramowania pośredniego redux, które należy wziąć pod uwagę podczas projektowania aplikacji redux, jest redux-observable. Jest on oparty na RxJS.

W tym przypadku redux-actions są zaimplementowane jako strumienie RxJS, więc masz strumień akcji i strumień stanu. Korzystając z redux-observable, można tworzyć epiki opisujące połączenia między akcjami. O eposach można myśleć jak o sagach z redux-saga.

Na razie nie chcę zagłębiać się w eposy (i sagi), ale w przyszłości możecie spodziewać się osobnych artykułów na ich temat.

Podsumowując – sagi i eposy mają znaczny próg wejścia, więc ty i twój zespół powinniście pomyśleć dwa razy, zanim zdecydujecie się z nich skorzystać. Nie oznacza to, że się mylą. Wszystko zależy od wymagań projektu i kwalifikacji zespołu.

Nie skłamię jednak, jeśli powiem, że redux-thunk jest dobrym wyborem w 90% przypadków.

Nowoczesny redux z haczykami

Świat Reacta można podzielić na dwie epoki: przed wprowadzeniem haków i po ich wprowadzeniu.

Wcześniej istniała funkcja connect dostarczana przez react redux i można było mapować stan i wysyłać do rekwizytów komponentów. Ponadto połączony komponent mógł przekazywać rekwizyty z komponentu nadrzędnego, więc konieczne było połączenie rekwizytów z komponentów i redux.

Pisanie za pomocą tej metody dodało jeszcze więcej szablonu redux do kodu, aby dodać komponent potomny, który ma dostęp do sklepu redux do drzewa komponentów.

Na szczęście mamy teraz haki i wszystko wygląda na prostsze.

Hooks

Nowy interfejs API „hooks” Reacta daje funkcjom możliwość korzystania z lokalnych stanów komponentów, wykonywania efektów ubocznych itd. React pozwala nam również pisać własne haki, dzięki czemu możemy wyodrębnić haki wielokrotnego użytku, aby dodać własne zachowanie do wbudowanych haków Reacta. React-Redux ma swoje standardowe API haków, które pozwalają komponentom Reacta subskrybować magazyny Reduxa, odczytywać stan i wysyłać akcje.

useSelector

Hak useSelector umożliwia odczytanie stanu z redux store. Każde wywołanie useSelector() tworzy indywidualną subskrypcję do sklepu Redux.

Spójrzmy na przykład komponentu react, który używa useSelector:

import React from 'react'
import { useSelector } from 'react-redux'

export const UserDetails = () => {
  const user = useSelector(state => state.user)
  return <h1>Hello, {user.name}</h1>
}

useDispatch

Hak useDispatch zwraca odwołanie do funkcji wysyłania z magazynu Redux. Dzięki temu można wysyłać akcje w komponencie react zgodnie z potrzebami.

import React from 'react'
import { useDispatch } from 'react-redux'

export const LogOut = ({ value }) => {
  const dispatch = useDispatch()

  return (
    <button onClick={() => dispatch({ type: 'LOG_OUT' })}>
      Log out
    </button>
  )
}

Jak widać, korzystanie z Redux z hakami jest dość proste i należy pamiętać, że jest to zalecane podejście (zamiast używania funkcji connect).

Szablon kodu Redux

Skupmy się teraz na czymś, co jest sporą wadą reduxa – boilerplate kodu. Kiedy tworzysz nową aplikację, konfigurujesz redux i jesteś gotowy do pracy… musisz napisać dużo kodu: reduktory, kreatory akcji. Zamiast tego nie jest to przyjemne, bardziej frustrujące, ale jest na to rozwiązanie!

Redux toolkit

Redux toolkit to opiniowany zestaw narzędzi, które mogą pomóc w tworzeniu kodu redux i skupieniu się na podstawowej logice, której potrzebuje aplikacja. Dzięki temu zestawowi narzędzi można pisać mniej kodu i wykonywać więcej pracy w tym samym czasie. Zestaw narzędzi Redux może pomóc w konfiguracji sklepu, tworzeniu reduktorów, niezmiennej logice aktualizacji i nie tylko.

Spójrz na przykłady tutaj: https://redux-toolkit.js.org/tutorials/quick-start.

Redux DevTools

Redux DevTools to rozszerzenie przeglądarki, które pozwala zobaczyć stan sklepu Redux w dowolnym momencie. W ten sposób możemy podróżować w czasie za pomocą naszej aplikacji – gdy zachodzą różne zmiany.

Jeśli aplikacja zacznie wysyłać więcej akcji, oprogramowanie sprawdzi interakcję użytkownika ze wszystkimi funkcjami za pomocą Redux DevTools. Jest to przydatne do debugowania w miarę rozwoju aplikacji, więc posiadanie bieżącego dziennika aktualizacji stanu sklepu redux zapewni cenny wgląd w to, jak aplikacja wygląda tak, jak wygląda.

Najbardziej podoba mi się sprawdzanie akcji, aktualnego stanu i podróżowanie w czasie. Zdecydowanie zaleca się korzystanie z Redux DevTools do debugowania aplikacji redux.

Redukcja testów

Redux to po prostu biblioteka, która zapewnia przestrzeganie określonego wzorca aktualizacji naszego globalnego stanu. Czy powinniśmy testować jednostkowo sklepy, reduktory, akcje i tak dalej?

Moim zdaniem nie powinniśmy. Redux jest szczegółem implementacji i powinien być ukryty w testach, nawet jeśli myślę o oprogramowaniu pośredniczącym redux. Z perspektywy testu, nie musisz używać thunków, sag czy eposów. Istotne jest to, że państwo powinno zostać zmienione.

Dlatego zalecam testowanie redux bardziej integralnie niż jednostki.

Na przykład, zamiast testować akcje i reduktory, przetestuj komponent, który odczytuje dane i uruchamia akcje. Przetestuj go z perspektywy użytkownika i upewnij się, że wyniki są takie, jakie powinny być.

Samouczek React Redux dla początkujących: Kompletny przewodnik

Najbardziej uproszczony samouczek Redux, którego potrzebuję, gdy go rozgryzam. Zawiera Redux Toolbox i haki Redux! Istnieje wiele samouczków redux, ale wiele z nich jest przestarzałych, więc planuję napisać nowy, który będzie aktualny z podejściami i technikami, które poznaliśmy już w 2021 roku. Bądź na bieżąco!

Podsumowanie

Na koniec chcę powiedzieć, że Redux jest złożonym sposobem zarządzania stanem w aplikacjach reactowych i nadal jest opcją w 2021 roku dla silnika zarządzania stanem dla aplikacji reactowych. Hooki dostarczane przez bibliotekę są łatwe w użyciu i wydajne. Dzięki zestawowi narzędzi redux istnieje również sposób na uniknięcie dużej ilości kodu standardowego redux.

W niektórych przypadkach Redux jest dobrym wyborem, a nawet jeśli wybierzesz Redux, musisz wybrać inne rzeczy: jakiego oprogramowania pośredniczącego powinienem użyć?

Redux-thunk, redux-saga czy redux-observable?

Oprogramowanie pośredniczące może pomóc w zarządzaniu efektami ubocznymi i logiką asynchroniczną na różne sposoby. Również poziom ich złożoności jest różny (thunks są najprostsze).

Czy potrzebuję redux?

Czy kolejne pytanie dotyczy architektury? Czy potrzebujesz redux i event sourcingu? Może alternatywy takie jak MobX, React Query, lub SWR będzie lepsze dla Ciebie?

Co więcej, Facebook aktywnie pracuje nad czymś nowym w zakresie zarządzania stanem w aplikacjach reactowych. Sprawdź Recoil.

Czy migrować z redux?

Ostatnie pytanie brzmi, czy mając aplikację redux, powinienem migrować do czegoś innego?

Byłem zafascynowany tym, jak redux stał się popularny kilka lat temu i jestem równie zafascynowany tym, jak nagle jego popularność spadła.

Kiedy myślisz o migracji z redux, musisz mieć dobre powody. Migracja z powodu odrzucenia przez społeczność nie jest powodem.

Jeśli po kilku latach okazało się, że wybór reduxa nie był najlepszy, to tylko podkreśla znaczenie designu i wyboru wzorcowej architektury dla konkretnego projektu.

Tak więc, jeśli masz powody i pieniądze, migruj z redux, ale jeśli migrujesz bez żadnego powodu. Proszę, zrezygnuj z tego.