Skip to content
State manager with a focus of all needs
TypeScript JavaScript
Branch: master
Clone or download
artalar Merge pull request #274 from belozer/issues-265
docs: goals / add framework-agnostic
Latest commit 2174ffa Jan 15, 2020

reatom logo

npm npm type definitions npm bundle size GitHub

Reatom is declarative and reactive state manager, designed for both simple and complex applications.

Goals and features

  • 🐣 simple abstraction and friendly DX: minimum boilerplate and tiny API
  • ❗️ static typed: best type inferences
  • performance: performant updates for partial state changes
  • 🗜 small size: 2 KB gzipped
  • 📦 modular: reusable instances (SSR)
  • 🍴 lazy: solution for code splitting out of the box
  • 🔌 framework-agnostic: independent and self-sufficient
  • 🧪 testing: simple mocking
  • 🛠 debugging: immutable data, devtools (redux ecosystem support by adapter)
  • 🔮 deterministic: declarative and predictable specification of state shape and its mutations
  • 👴 ES5 support: by polyfills
  • 🧯 reliable: predictable flow exceptions
  • synchronous glitch free: resolve diamond problem
  • simple integration with other libraries (Observable, redux ecosystem, etc)
  • awkward to write bad code
  • easy to write good code


Reatom is a blend of the one-way data flow (by flux and global store) and decentralized atoms for deterministic and flexible description of state and its changes.

Inspired by redux, kefir, effector

Data flow diagram:

reatom data flow


npm i @reatom/core


yarn add @reatom/core


Open in CodeSandbox

import {
} from '@reatom/core'

/** Actions */
const increment = declareAction()
const add = declareAction()

/** Atoms */
const countAtom = declareAtom(1, on => [
  on(increment, state => state + 1),
  on(add, (state, payload) => state + payload),
const isOddAtom = map(countAtom, count => Boolean(count % 2))
const rootAtom = combine({ count: countAtom, isOdd: isOddAtom })

/** Store */
const store = createStore(rootAtom)

store.subscribe(countAtom, count => console.log('count: ', count))
store.subscribe(isOddAtom, isOdd => console.log('isOdd: ', isOdd))

// count: 2
// isOdd: false

// count: 4
// here `isOdd` subscriber will not be called because its value is not changed


Package Version Size
@reatom/core npm npm bundle size
@reatom/react npm npm bundle size
@reatom/observable npm npm bundle size
@reatom/babel-plugin npm -
@reatom/debug npm npm bundle size


Why another state manager? The reason is dissatisfaction with existing solutions that do not cover our requirements. We strive to create a lightweight state manager that combines the best solutions proven over the years and personal experience.

Show problems in popular solutions

NOTE. Please do not consider these arguments as a way to dissuade you from using these libraries. These are very interesting projects and they deserve your attention. This list only shows the motivation for creating Reatom.


link to repository

  • Selectors are not inspectable (lacking in devtools).
  • Difficult static type inference (every selector must know the full path to parent state).
  • Hard for modular architecture (every selector must know about parent state).
  • Separation of interfaces (reducers and selectors) complicates the prototyping of separated domains.
  • Selectors - manual API for state. They must be manually described and memoized.
  • Selectors are executed after state change at subscriptions - error in selector will throw an error. Also it is not possible (possible, but really hard) to restore the previous valid state.
  • Classic reducer API and [static] type descriptions have a lot of boilerplate.
  • Selectors are "runtime" oriented; if a "feature" uses any part of the state (by selector) and later you remove this part, you will get an error only when mounting your "feature" at runtime (if you do not have static typing). The single solution is to connect all features statically by imports.
  • Middleware is a confusing pattern that can unexpectedly modify the behavior of the store. For example, actions for redux-thunk do not log.

    Some problems can be solved by various fabric functions and third party libriaries. This makes it diffcuilt to reuse solutions across multiple projects.


link to repository

  • Effector is about atomic stores — it uses stateful approach that has certain problems:

    • probable memory leaks

      Like any other observable libraries

    • difficult [store] instance reusability (concurrency problems with SSR)

      It can be solved, but it is better to solve it by design of a library architecture and API

  • Asynchronous and probably cyclic dependencies specification

    show example
    const store = createStore(0)
    const event = createEvent()
    store.on(event, (state, payload) => payload)
    // console.log: 1000
    // In any time and in any project part
    const otherEvent = createEvent()
    store.on(otherEvent, (state, payload) => payload)
    // console.log: 2000
  • The size

  • Throw in reducer does not cancel the computations in other reducers


link to repository


Follow us on Twitter @reatomjs


Mass media



Thanks goes to these wonderful people (emoji key):

Arutyunyan Artyom

💻 🤔 ⚠️ 🚇 👀 💡 📖

Sergey Belozyorcev

💻 🤔 ⚠️ 🚇 👀 🎨 💡 📖


💻 🤔 🚇 ⚠️ 📦 🔌 🔧



Taymuraz Kaytmazov




Shmavon Gazanchyan

📖 🚇

Ilya Zaitsev


Ivakhnenko Dmitry


Paul Ekshmidt


Лубяной Евгений


This project follows the all-contributors specification. Contributions of any kind welcome!

You can’t perform that action at this time.