State Management and Data Fetching Solutions for React Applications
effector, mobx, react-query, recoil, redux, redux-saga, redux-thunk, xstate, and zustand are libraries that help manage state and side effects in JavaScript applications, particularly in React. They address different aspects of state management: global state (redux, zustand, recoil, mobx, effector), asynchronous data fetching and caching (react-query), complex state machines (xstate), and middleware for handling side effects in Redux-based apps (redux-thunk, redux-saga). Each offers distinct mental models, APIs, and trade-offs around predictability, boilerplate, reactivity, and developer experience.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
State Management Deep Dive: effector, mobx, react-query, recoil, redux, redux-saga, redux-thunk, xstate, zustand
Managing state in modern JavaScript apps goes far beyond useState. The libraries in this comparison solve different problems: some handle local UI state, others manage server data, complex workflows, or global application state. Let’s break down how they work in practice.
🧠 Core Mental Models: How Each Library Thinks About State
redux – Predictable State Container
Redux enforces a single source of truth with immutable updates via pure reducer functions. Every change is triggered by a plain action object.
// redux
import { createStore } from 'redux';
const initialState = { count: 0 };
const reducer = (state = initialState, action) => {
if (action.type === 'increment') return { count: state.count + 1 };
return state;
};
const store = createStore(reducer);
store.dispatch({ type: 'increment' });
zustand – Minimalist Hook-Based Store
Zustand skips reducers and actions. You define state and methods together in a single hook-like function.
// zustand
import { create } from 'zustand';
const useStore = create((set) => ({
count: 0,
increment: () => set((state) => ({ count: state.count + 1 }))
}));
// In component
const { count, increment } = useStore();
recoil – Atomic State Graph
Recoil models state as atoms (units) and selectors (derived state). Components subscribe only to what they use.
// recoil
import { atom, selector, useRecoilState, useRecoilValue } from 'recoil';
const countAtom = atom({ key: 'count', default: 0 });
const doubledCount = selector({
key: 'doubledCount',
get: ({ get }) => get(countAtom) * 2
});
// In component
const [count, setCount] = useRecoilState(countAtom);
const double = useRecoilValue(doubledCount);
mobx – Transparent Reactive Programming
MobX wraps state in observables. When you mutate them, all observers (like React components) update automatically.
// mobx
import { makeAutoObservable } from 'mobx';
import { observer } from 'mobx-react-lite';
class Counter {
count = 0;
constructor() { makeAutoObservable(this); }
increment() { this.count += 1; }
}
const counter = new Counter();
// In component (must be observer)
const CounterComponent = observer(() => <div>{counter.count}</div>);
effector – Event-Driven Reactive System
Effector uses stores (state), events (triggers), and effects (async operations). It’s framework-agnostic and composable.
// effector
import { createEvent, createStore, createEffect } from 'effector';
const increment = createEvent();
const $count = createStore(0).on(increment, (state) => state + 1);
// In React
import { useUnit } from 'effector/react';
const Counter = () => {
const [count, inc] = useUnit([$count, increment]);
return <button onClick={inc}>{count}</button>;
};
xstate – Explicit State Machines
XState defines states and allowed transitions. Invalid transitions are impossible by design.
// xstate
import { createMachine, interpret } from 'xstate';
const toggleMachine = createMachine({
id: 'toggle',
initial: 'inactive',
states: {
inactive: { on: { TOGGLE: 'active' } },
active: { on: { TOGGLE: 'inactive' } }
}
});
const service = interpret(toggleMachine).start();
service.send('TOGGLE'); // moves to 'active'
react-query – Server-State Synchronization
React Query doesn’t manage UI state. It handles fetching, caching, and syncing data from APIs.
// react-query
import { useQuery, useMutation } from '@tanstack/react-query';
// Fetching
const { data, isLoading } = useQuery({
queryKey: ['todos'],
queryFn: () => fetch('/api/todos').then(res => res.json())
});
// Mutating
const mutation = useMutation({
mutationFn: (newTodo) => fetch('/api/todos', { method: 'POST', body: newTodo }),
onSuccess: () => queryClient.invalidateQueries({ queryKey: ['todos'] })
});
redux-thunk – Simple Async Middleware
Thunks let action creators return functions that dispatch actions asynchronously.
// redux-thunk
const fetchUser = (id) => async (dispatch) => {
dispatch({ type: 'FETCH_USER_START' });
try {
const user = await api.getUser(id);
dispatch({ type: 'FETCH_USER_SUCCESS', payload: user });
} catch (err) {
dispatch({ type: 'FETCH_USER_ERROR', payload: err });
}
};
// Dispatch
store.dispatch(fetchUser(123));
redux-saga – Complex Side Effect Management
Sagas use generator functions to describe side effects declaratively, making them highly testable.
// redux-saga
import { call, put, takeEvery } from 'redux-saga/effects';
function* fetchUser(action) {
try {
const user = yield call(api.getUser, action.payload.id);
yield put({ type: 'FETCH_USER_SUCCESS', payload: user });
} catch (err) {
yield put({ type: 'FETCH_USER_ERROR', payload: err });
}
}
function* watchFetchUser() {
yield takeEvery('FETCH_USER_REQUEST', fetchUser);
}
⚙️ Handling Asynchronous Logic
Not all state libraries handle async the same way:
react-queryis purpose-built for async data. It manages loading states, retries, caching, and background updates automatically.redux-thunkis the simplest way to do async in Redux but offers no advanced control.redux-sagagives full control over complex async flows (e.g., race conditions, cancellation) but requires learning generators.effectorhas first-classcreateEffectfor async with built-in pending/error states.mobxlets you write async logic directly in methods usingasync/await.zustandsupports async in setters just like regular functions.xstatecan invoke promises or callbacks during state transitions.recoilusesselectorFamilywith async functions, but error/loading states must be managed manually.reduxalone cannot handle async — it requires middleware like thunk or saga.
📦 Integration with React
- Tight coupling:
recoil,react-query, andmobx-react-liteare React-specific. - Framework agnostic:
effector,xstate,redux,zustand(though commonly used with React) work anywhere. - Provider requirements:
redux,mobx, andrecoilrequire context providers at the root.zustandandeffectordo not.
🔁 Performance Characteristics
- Granular updates:
recoil,mobx,zustand, andeffectoravoid unnecessary re-renders by letting components subscribe to specific state slices. - Global re-renders: Vanilla
reduxcauses all connected components to re-render on any state change unless you useReact.memoorcreateSelector. - Computed values:
recoilselectors,mobxcomputed, andeffectorderived stores cache results until dependencies change.
🛠️ Boilerplate and Learning Curve
| Library | Boilerplate | Learning Curve |
|---|---|---|
zustand | Very Low | Low |
mobx | Low | Medium |
react-query | Low | Low |
recoil | Medium | Medium |
effector | Medium | Medium-High |
xstate | Medium | High |
redux (+RTK) | Medium | Medium |
redux-thunk | Low | Low |
redux-saga | High | High |
🧩 When to Combine Libraries
It’s common — and often wise — to use more than one:
redux+react-query: Use Redux for UI state and React Query for server state.zustand+xstate: Use Zustand for simple global state and XState for complex feature flows.mobx+react-query: MobX for client state, React Query for API data.
Avoid mixing multiple global state managers (e.g., Redux + Zustand) unless you have a clear boundary.
✅ Summary: Key Strengths
| Library | Best For |
|---|---|
effector | Framework-agnostic reactive systems |
mobx | Mutable-style code with auto-tracking |
react-query | Server data caching and synchronization |
recoil | Fine-grained React state with derived values |
redux | Predictable, debuggable global state |
redux-saga | Complex, testable side effects in Redux |
redux-thunk | Simple async logic in Redux |
xstate | Visualizable, safe state transitions |
zustand | Lightweight, hook-based global state |
💡 Final Guidance
- If you’re fetching data from APIs, start with
react-query— it solves 80% of async data problems out of the box. - For global UI state in React,
zustandis the sweet spot for most teams: minimal setup, no providers, great performance. - Need strict predictability and dev tools?
reduxwith Redux Toolkit remains a solid choice. - Building a wizard, modal flow, or device interface? Model it with
xstateto eliminate invalid states. - Avoid
redux-thunkfor anything beyond basic API calls; preferredux-sagaor switch to a non-Redux solution if async logic grows.
Choose based on your problem, not trends. Most apps don’t need all nine — pick one or two that match your actual complexity.
How to Choose: redux-saga vs recoil vs effector vs mobx vs react-query vs redux vs redux-thunk vs xstate vs zustand
- redux-saga:
Choose
redux-sagawhen managing complex, long-running side effects (like websockets or retry logic) in a Redux app. It uses generator functions for testable, declarative control flow, but has a steep learning curve and adds considerable complexity for simple use cases. - recoil:
Choose
recoilif you’re building a React-only app and want atomic, selector-based state that scales from simple to complex without context bottlenecks. It integrates deeply with React’s concurrent features, but is tightly coupled to React and may add complexity for teams unfamiliar with its atom/selector model. - effector:
Choose
effectorif you want a reactive, event-driven architecture that works outside React and supports fine-grained updates with minimal re-renders. It’s well-suited for complex logic that needs to be decoupled from UI frameworks, but requires learning its unique concepts like stores, events, and effects. - mobx:
Choose
mobxif you prefer writing mutable-like code that automatically tracks dependencies and updates observers. It reduces boilerplate significantly and works well for medium-sized apps where performance isn’t bottlenecked by frequent small updates, but it can make debugging harder due to implicit reactivity. - react-query:
Choose
react-querywhen your app heavily relies on server-state (data from APIs) and you need built-in caching, background refetching, mutations, and optimistic updates. It’s not a global state manager for UI state, but excels at synchronizing client and server data with minimal manual effort. - redux:
Choose
reduxif you need a predictable, centralized store with strict unidirectional data flow, time-travel debugging, and strong ecosystem support. It’s ideal for large teams or apps requiring auditability, but comes with significant boilerplate unless paired with modern tooling like Redux Toolkit. - redux-thunk:
Choose
redux-thunkfor basic async logic in Redux apps, like simple API calls that dispatch actions before and after. It’s lightweight and easy to learn, but lacks advanced features for complex workflows — making it suitable only for straightforward side effects. - xstate:
Choose
xstatewhen your feature involves explicit, visualizable state transitions (e.g., wizards, modals, or device control). Its finite state machine model prevents invalid states and improves maintainability for complex flows, but introduces overhead for simple CRUD-style state. - zustand:
Choose
zustandfor a lightweight, hook-based global state solution with minimal boilerplate and no context providers. It’s ideal for most React apps needing shared state without Redux’s ceremony, offers great performance via selective subscriptions, and supports middleware and persistence out of the box.
Popular Comparisons
README for redux-saga
redux-saga
See our website for more information.