State Management and Reactive Streams in Frontend Architecture
redux, mobx, effector, and rxjs are all tools for managing state and data flow in JavaScript applications, but they solve the problem in very different ways. redux relies on a single immutable store and pure functions to manage state changes, making it predictable but verbose. mobx uses mutable state with automatic dependency tracking, allowing for a more object-oriented style. effector focuses on isolated units of state and events with a functional approach, designed for performance and type safety. rxjs is a library for reactive programming using observables, handling streams of data over time rather than just static state.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
State Management and Reactive Streams in Frontend Architecture
redux, mobx, effector, and rxjs are all tools for managing state and data flow in JavaScript applications, but they work differently under the hood. Let's compare how they tackle common problems like updating data, connecting to UI, and handling async logic.
π§ Core Mental Model: Store vs Observable vs Unit
redux uses a single immutable store for the whole app.
- State is read-only and changed by dispatching actions.
- You write pure functions called reducers to specify how state changes.
// redux: Define slice and store
import { configureStore, createSlice } from '@reduxjs/toolkit';
const counterSlice = createSlice({
name: 'counter',
initialState: { value: 0 },
reducers: { increment: (state) => { state.value += 1; } }
});
const store = configureStore({ reducer: { counter: counterSlice.reducer } });
mobx uses mutable state with automatic tracking.
- You mark objects as observable, and MobX watches for changes.
- Components re-render automatically when observed data changes.
// mobx: Create observable store
import { makeAutoObservable } from 'mobx';
class CounterStore {
value = 0;
constructor() { makeAutoObservable(this); }
increment() { this.value += 1; }
}
const store = new CounterStore();
effector uses isolated units called stores and events.
- You create separate stores for different pieces of state.
- Events trigger updates, and stores hold the data.
// effector: Create store and event
import { createStore, createEvent } from 'effector';
const increment = createEvent();
const $counter = createStore(0).on(increment, (count) => count + 1);
rxjs uses streams of data called observables.
- Data flows over time, and you subscribe to receive values.
- It is not a state manager by default, but
BehaviorSubjectcan hold state.
// rxjs: Create state stream
import { BehaviorSubject } from 'rxjs';
const counter$ = new BehaviorSubject(0);
// Update value
counter$.next(counter$.value + 1);
βοΈ Updating State: Dispatch vs Action vs Event vs Next
redux requires dispatching an action object.
- You cannot change state directly; you send a request to change it.
- This makes changes explicit and easy to log.
// redux: Dispatch action
store.dispatch({ type: 'counter/increment' });
// Or with toolkit slice actions
store.dispatch(counterSlice.actions.increment());
mobx allows direct mutation inside actions.
- You call methods that change properties directly.
- MobX detects the change and notifies listeners.
// mobx: Call action method
store.increment();
// Or direct mutation if auto-observable
store.value += 1;
effector triggers an event to update the store.
- Events are functions you call to pass payload data.
- Stores listen to events and update based on logic.
// effector: Trigger event
increment();
// Or with payload
const setCount = createEvent();
setCount(10);
rxjs pushes a new value into the stream.
- You call
next()on the subject to emit new data. - Subscribers receive the new value asynchronously.
// rxjs: Emit new value
counter$.next(5);
βοΈ React Integration: Selector vs Observer vs Unit vs Hook
redux uses hooks to select data from the store.
useSelectorsubscribes the component to specific state slices.useDispatchgives you the function to send actions.
// redux: React hooks
import { useSelector, useDispatch } from 'react-redux';
function Counter() {
const count = useSelector((state) => state.counter.value);
const dispatch = useDispatch();
return <button onClick={() => dispatch(increment())}>{count}</button>;
}
mobx wraps components to track usage.
observermakes a component react to changes in observable data.- It automatically re-renders when observed data changes.
// mobx: Observer component
import { observer } from 'mobx-react-lite';
const Counter = observer(({ store }) => {
return <button onClick={() => store.increment()}>{store.value}</button>;
});
effector binds stores directly to components.
useUnithooks into stores and events efficiently.- It prevents unnecessary re-renders by tracking specific units.
// effector: React unit hook
import { useUnit } from 'effector-react';
function Counter() {
const count = useUnit($counter);
const inc = useUnit(increment);
return <button onClick={inc}>{count}</button>;
}
rxjs requires a hook to subscribe to streams.
- Libraries like
rxjs-reactor custom hooks are needed. - You must manage subscription cleanup manually or via hooks.
// rxjs: Custom hook pattern
import { useEffect, useState } from 'react';
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const sub = counter$.subscribe(setCount);
return () => sub.unsubscribe();
}, []);
return <button onClick={() => counter$.next(count + 1)}>{count}</button>;
}
β³ Handling Async Logic: Thunks vs Flows vs Effects vs Operators
redux uses middleware like Thunks or Sagas.
- Thunks allow functions that dispatch actions after async work.
- Sagas use generators for complex async flows.
// redux: Async thunk
import { createAsyncThunk } from '@reduxjs/toolkit';
const fetchData = createAsyncThunk('data/fetch', async () => {
const res = await fetch('/api');
return res.json();
});
mobx uses flow for async actions.
- It wraps async functions to track state changes during awaits.
- Looks like async/await but integrates with MobX tracking.
// mobx: Async flow
import { flow } from 'mobx';
class Store {
fetchData = flow(function* () {
const res = yield fetch('/api');
this.data = yield res.json();
});
}
effector uses effects for side effects.
- Effects are units that handle async operations and return promises.
- They integrate with stores via
sampleorattach.
// effector: Async effect
import { createEffect } from 'effector';
const fetchData = createEffect(async () => {
const res = await fetch('/api');
return res.json();
});
rxjs uses operators to manage async streams.
- Operators like
switchMapormergeMaphandle requests. - You can cancel requests by unsubscribing or switching streams.
// rxjs: Async operator
import { switchMap } from 'rxjs/operators';
stream$.pipe(
switchMap(() => fetch('/api').then(res => res.json()))
).subscribe(data => console.log(data));
π οΈ Debugging and Tooling
redux has the most mature DevTools.
- Time-travel debugging lets you rewind state changes.
- Action logs show exactly what changed and why.
// redux: DevTools setup
// Automatically included in configureStore
const store = configureStore({ reducer: { ... } });
mobx has DevTools for tracking reactions.
- You can see which observables triggered which components.
- Less focus on history, more on dependency graphs.
// mobx: DevTools
import { configure } from 'mobx';
configure({ enforceActions: 'always' });
effector has its own DevTools extension.
- Shows store updates and event triggers visually.
- Supports tracing event chains across the app.
// effector: DevTools
import { inspect } from '@effector/inspect';
inspect();
rxjs relies on logging or marble diagrams.
- No standard UI DevTools for React integration.
- Developers often use
tapoperator to log stream values.
// rxjs: Logging stream
import { tap } from 'rxjs/operators';
stream$.pipe(tap(val => console.log(val))).subscribe();
π€ Similarities: Shared Ground Between Libraries
While the differences are clear, these libraries also share many core ideas and tools. Here are key overlaps:
1. π Reactive Updates
- All four libraries update the UI when data changes.
- They avoid manual DOM manipulation by syncing state to view.
// Example: All trigger UI updates
// redux: dispatch -> reducer -> selector -> render
// mobx: action -> observable -> observer -> render
// effector: event -> store -> unit -> render
// rxjs: next -> subscribe -> setState -> render
2. π¦ Ecosystem Support
- All have dedicated React bindings or community hooks.
- Supported by TypeScript with strong type definitions.
// Example: TypeScript support
// redux: TypedUseSelectorHook
// mobx: IReactionDisposer
// effector: Store<T>
// rxjs: Observable<T>
3. β‘ Performance Optimization
- All aim to minimize unnecessary re-renders.
- They provide mechanisms to select specific data slices.
// Example: Selecting data
// redux: useSelector(state => state.user)
// mobx: observer accesses this.props.user
// effector: useUnit($user)
// rxjs: distinctUntilChanged()
π Summary: Key Differences
| Feature | redux | mobx | effector | rxjs |
|---|---|---|---|---|
| State Model | ποΈ Immutable Single Store | 𧱠Mutable Objects | 𧩠Isolated Units | π Streams |
| Update Method | π€ Dispatch Actions | βοΈ Direct Mutation | β‘ Trigger Events | β‘οΈ Emit Values |
| React Binding | πͺ useSelector | π§ observer | π useUnit | π subscribe / Hooks |
| Async Handling | 𧡠Thunks / Sagas | π flow | π― effects | π οΈ Operators |
| Learning Curve | π Steep (Boilerplate) | π Low (Magic) | π Medium (Functional) | π High (Reactive) |
| DevTools | π Excellent (Time Travel) | β Good (Reaction Graph) | β Good (Unit Trace) | β οΈ Limited (Logging) |
π‘ The Big Picture
redux is like a strict ledger π β great for teams that need predictability, audit trails, and a standard pattern everyone knows. Ideal for large enterprise apps where state changes must be explicit.
mobx is like a spreadsheet π β perfect for teams who want to write less code and prefer mutable state. It shines in complex domain models where automatic tracking saves time.
effector is like a circuit board π β best for developers who want high performance and type safety without Redux verbosity. It works well for apps that need fine-grained control over re-renders.
rxjs is like a water pipe system π° β designed for handling complex streams of events over time. It is the go-to for heavy async logic, websockets, or event-heavy interfaces.
Final Thought: There is no single best tool. redux offers stability, mobx offers speed of development, effector offers balance and performance, and rxjs offers power for streams. Choose based on your team's comfort with functional vs object-oriented styles and the complexity of your data flow.
How to Choose: rxjs vs redux vs mobx vs effector
- rxjs:
Choose
rxjsif your application deals heavily with asynchronous events, streams, or complex event composition rather than simple UI state. It is perfect for handling websockets, user input streams, or canceling ongoing requests. It is less about UI state management and more about managing data flows over time. - redux:
Choose
redux(specifically Redux Toolkit) if you need a predictable state container with a large ecosystem and strict unidirectional data flow. It is best for teams that value explicit state changes and time-travel debugging, especially in large organizations where consistency is key. It is the standard choice when integrating with many third-party libraries that expect a Redux store. - mobx:
Choose
mobxif you prefer mutable state and want to write less boilerplate code. It is suitable for applications where state logic resembles object-oriented design, allowing you to modify state directly without dispatchers. It shines in rapid prototyping and complex domain models where automatic dependency tracking reduces manual wiring. - effector:
Choose
effectorif you want a balance between structure and flexibility without the boilerplate of Redux. It is ideal for large applications where type safety and performance are critical, as it avoids re-renders by default and has a unique unit-based architecture. It works well for teams that prefer functional programming patterns but find Redux too rigid.
Popular Comparisons
README for rxjs
RxJS: Reactive Extensions For JavaScript
The Roadmap from RxJS 7 to 8
Curious what's next for RxJS? Follow along with Issue 6367.
RxJS 7
FOR 6.X PLEASE GO TO THE 6.x BRANCH
Reactive Extensions Library for JavaScript. This is a rewrite of Reactive-Extensions/RxJS and is the latest production-ready version of RxJS. This rewrite is meant to have better performance, better modularity, better debuggable call stacks, while staying mostly backwards compatible, with some breaking changes that reduce the API surface.
Versions In This Repository
- master - This is all of the current work, which is against v7 of RxJS right now
- 6.x - This is the branch for version 6.X
Most PRs should be made to master.
Important
By contributing or commenting on issues in this repository, whether you've read them or not, you're agreeing to the Contributor Code of Conduct. Much like traffic laws, ignorance doesn't grant you immunity.
Installation and Usage
ES6 via npm
npm install rxjs
It's recommended to pull in the Observable creation methods you need directly from 'rxjs' as shown below with range.
If you're using RxJS version 7.2 or above, you can pull in any operator you need from the same spot, 'rxjs'.
import { range, filter, map } from 'rxjs';
range(1, 200)
.pipe(
filter(x => x % 2 === 1),
map(x => x + x)
)
.subscribe(x => console.log(x));
If you're using RxJS version below 7.2, you can pull in any operator you need from one spot, under 'rxjs/operators'.
import { range } from 'rxjs';
import { filter, map } from 'rxjs/operators';
range(1, 200)
.pipe(
filter(x => x % 2 === 1),
map(x => x + x)
)
.subscribe(x => console.log(x));
CDN
For CDN, you can use unpkg:
https://unpkg.com/rxjs@^7/dist/bundles/rxjs.umd.min.js
The global namespace for rxjs is rxjs:
const { range } = rxjs;
const { filter, map } = rxjs.operators;
range(1, 200)
.pipe(
filter(x => x % 2 === 1),
map(x => x + x)
)
.subscribe(x => console.log(x));
Goals
- Smaller overall bundles sizes
- Provide better performance than preceding versions of RxJS
- To model/follow the Observable Spec Proposal to the observable
- Provide more modular file structure in a variety of formats
- Provide more debuggable call stacks than preceding versions of RxJS
Building/Testing
npm run compilebuild everythingnpm testrun testsnpm run dtslintrun dtslint tests
Adding documentation
We appreciate all contributions to the documentation of any type. All of the information needed to get the docs app up and running locally as well as how to contribute can be found in the documentation directory.