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
• 🧪 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

Description

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:

Installation

npm i @reatom/core

or

yarn add @reatom/core

Usage

Open in CodeSandbox

import {
  declareAction,
  declareAtom,
  map,
  combine,
  createStore,
} 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))

store.dispatch(increment())
// count: 2
// isOdd: false

store.dispatch(add(2))
// count: 4
// here `isOdd` subscriber will not be called because its value is not changed

Packages

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

Motivation

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.

Redux

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.

Effector

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)
  store.watch(console.log)
  
  const event = createEvent()
  store.on(event, (state, payload) => payload)
  
  event(1000)
  // console.log: 1000
  
  // In any time and in any project part
  const otherEvent = createEvent()
  store.on(otherEvent, (state, payload) => payload)
  
  otherEvent(2000)
  // console.log: 2000

• The size

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

MobX

link to repository

• Large bundle size, unstandardized syntax (decorators), ES5 limitations.
• Doesn't move to separate model and view.
• Runtime semantic and mutable state (difficult to debug).
• Proxy pattern lacks a visual part of code semantic.
• It is complicated under the hood and it can be complicated when one has to work with complex data-structures
• And others...

Community

Follow us on Twitter @reatomjs

Telegram

• @reatom_en — english
• @reatom_ru — russian

Mass media

• Reatom vs Redux. Part 1 (5minreact, russian podcast)
• Reatom vs MobX. Part 2 (5minreact, russian podcast)
• Reatom. Rethink of Redux (RND JS, russian meetup)
• Begebot №29. State managers and reatom as the pinnacle of evolution (russian podcast)

---

Next:

• Glossary
• Examples
• FAQ
• Contributing

Contributors ✨

Thanks goes to these wonderful people (emoji key):

Arutyunyan Artyom 💻 🤔 ⚠️ 🚇 ✅ 👀 💡 📖	Sergey Belozyorcev 💻 🤔 ⚠️ 🚇 ✅ 👀 🎨 💡 📖	Alexey 💻 🤔 🚇 ⚠️ 📦 🔌 🔧	Anton 📖	Taymuraz Kaytmazov 📖	Ilya 📖	Shmavon Gazanchyan 📖 🚇
Ilya Zaitsev 📖	Ivakhnenko Dmitry 💻	Paul Ekshmidt 🚇	Лубяной Евгений 💻

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