DEV Community

Cover image for Why do I choose Effector instead of Redux or MobX?

Why do I choose Effector instead of Redux or MobX?

ilyalesik profile image Ilya Lesik Updated on ・6 min read

Effector is a brand new reactive state manager. Its ambitious team aims to solve all the problems that existing solutions have. Writing the core of the library from scratch took several attempts across six months, and recently the team released the first stable release.

In this article, I will show why I prefer using Effector for my new projects instead of other state managers. Let's get started with the Effector API.


Effector uses two concepts you might already be familiar with: store and event.

A store is an object that holds some value. We can create stores with the createStore helper:

import {createStore} from 'effector'

const counter = createStore(0) // create store with zero as default value // watch store changes

Stores are lightweight, so whenever you need to introduce some state to your app, you simply create a new store.

So how do we update our store? Events! You create events with the createEvent helper and have your store updated by reacting on them:

import {createStore, createEvent} from 'effector'

const increment = createEvent('increment')
const decrement = createEvent('decrement')
const resetCounter = createEvent('reset counter')

const counter = createStore(0)
  .on(increment, state => state + 1) // subscribe to the event and return new store value
  .on(decrement, state => state - 1)  

Event is like an "action" in Redux terms, and store.on(trigger, handler) is somewhat like createStore(reducer). Events are just functions that can be called from any place in your code.

Effector implements the Reactive Programming paradigm. Events and stores are considered as reactive entities (streams, in other words), they have a watch method which allows subscribing to events and store changes.

Integration with React

A component can connect to the store by calling the useStore hook from effector-react package. Effector events can be passed to child React elements as event handlers (onClick, etc.)

import React from 'react'
import ReactDOM from 'react-dom'
import {createStore, createEvent} from 'effector'
import {useStore} from 'effector-react'

const increment = createEvent('increment')
const decrement = createEvent('decrement')
const resetCounter = createEvent('reset counter')

const counter = createStore(0)
  .on(increment, state => state + 1)
  .on(decrement, state => state - 1)

const Counter = () => {
  const value = useStore(counter) // subscribe to store changes

  return (
      <div>Count: {value}</div>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
      <button onClick={resetCounter}>reset</button>

const App = () => <Counter />
const div = document.createElement('div')

Integration with other frameworks


There is effector-vue package.


Effector stores are Observable, so you don't need any additional packages to use them in Svelte. Simply prepend $ to the store's name in your template:

// Counter.svelte
<script context="module">
  import effector from 'effector/effector.umd.js';

  export const increment = createEvent('increment')
  export const decrement = createEvent('decrement')
  export const resetCounter = createEvent('reset counter')
  export const counter = effector.createStore(0)
    .on(increment, (n) => n + 1)
    .on(decrement, state => state - 1)

// App.svelte
  import { counter, increment, decrement, resetCounter } from './Counter.svelte'

<div>Count: {$counter}</div>
<button on:click={increment}>+</button>
<button on:click={decrement}>-</button>
<button on:click={resetCounter}>reset</button>

Side effects

With Effector you don't need thunks or sagas to handle side effects. Effector has a convenient helper called createEffect that wraps an async function and creates three events that your store can subscribe to: an initializer (the effect itself) and two resolvers called done and fail.

const getUser = createEffect('get user');
getUser.use(params => {
  return fetch(`${}`)
    .then(res => res.json())

// OR

const getUser = createEffect('get user', {
  handler: params => fetch(`${}`)
    .then(res => res.json())

const users = createStore([]) // <-- Default state
  // getUser.done is the event that fires whenever a promise returned by the effect is resolved
  .on(getUser.done, (state, {result, params}) => [...state, result])

Advanced usage: combine, map

One of the awesome features of Effector is computed stores. Computed stores can be created using either the combine helper or .map method of the store. This allows subscribing only to changes that matter to the particular component. In React apps, performance may be heavily impacted by unnecessary state updates, so Effector helps eliminate them.

combine creates a new store that calculates its state from several existing stores:

const balance = createStore(0)
const username = createStore('zerobias')

const greeting = combine(balance, username, (balance, username) => {
  return `Hello, ${username}. Your balance is ${balance}`
}) => console.log(data)) // Hello, zerobias. Your balance is 0

map allows creating derived stores:

const title = createStore("")
const changed = createEvent()

const length = => title.length)

title.on(changed, (oldTitle, newTitle) => newTitle) => console.log("new length is ", length)) // new length is 0

changed("hello") // new length is 5
changed("hello world") // new length is 11

Comparison with other state managers


  • Most projects that use Redux implement the whole application state in a single store. Having multiple stores isn't forbidden, but doing this right is kind of tricky. Effector is built to work with lots of different stores simultaneously.
  • Redux is very explicit but very verbose as well. Effector requires less boilerplate code, but all state dependencies are still explicit.
  • Redux was originally written in pure JS and without static typing in mind. Effector has much wider typing support out of the box, including type inference for most helpers and methods.
  • Redux has great dev tools. Effector somewhat lags right now, but the team already has plans for dev tools that visually represent your application as a graph of connected stores and events.


  • When minified and gzipped, MobX is almost 20kb (14.9kb + 4.6kb for React bindings), while Effector is less than 8 kb (5.8 kb + 1.7 kb for React).
  • MobX has a lot of magic inside: implicit subscriptions to observable data changes, "mutable" state objects that use Proxies under the hood to distribute updates, etc. Effector uses immutable state, explicitly combines stores' state and only allows changing it through events.
  • MobX encourages keeping your data model close to the view. With Effector, you can completely isolate the data model and keep your UI components' API clean & simple.
  • May be difficult to use with custom data-structures.


  • Strictly speaking, although RxJS solves many tasks, it's a reactive extensions library, not a state management tool. Effector, on the other hand, is designed specifically for managing application state and has a small API that is easy to learn.
  • RxJS is not 'glitch-free'. In particular, synchronous streams for computed data do not produce consistent updates by default: see an example on how different reactive state management tools handle this task.

Why did I choose Effector

Here's a list of things I consider to be Effector's advantages over most similar tools:

  • Expressive and laconic API.
  • Reactive programming paradigm at its core.
  • Stable, production-ready.
  • Great performance, also I don't see any memory leaks.
  • Motivated team, great community.


Effector is not a silver bullet, but it's certainly a fresh take on state management. Do not be afraid to try something new and diverge from the most popular solutions. Interested? Try Effector now!



Discussion (2)

Editor guide
erixtekila profile image
Eric Priou

Reminds me Undux.

dangdennis profile image
Dennis Dang

This has bucklescript types. Sold