artalar / Reatom

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

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, 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))

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

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

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

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

Packages

Package	Version	Size
@reatom/core
@reatom/react
@reatom/angular
@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.

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 and has a problems as a any Producers:
  • probable memory leaks, because an store existents controlled not by a consumers (subscribers), but by a data sources, that is a more common.

    if you have a source A and derived source B and C, even if only B has a subscribers and need to application workflow, C still be receiving an updates and calculate it, even if nobody need it.

  • difficult [store] instance reusability.

    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 - it less predictable than describe all dependencies with instance creation.
• The size (Reatom is 3 times lighter).
• 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
• Guides
  • Naming Conventions
  • File Structure
  • Code Splitting
  • Server Side Rendering
  • Migration from Redux
  • Inversion of control

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 🚇	Лубяной Евгений 💻	Nikita Stenin 💻 🚇	Alexander Zenov 💻	ivan-nemtinov 💻
Viktor Pasynok 💻

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