@reatom/core NPM

npm type definitions GitHub

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

IMPORTANT! Current state is Work In Progress. At the moment we do not recommend to use reatom in production, but... We look forward to your feedback and suggestions to improve the API
v1.0.0 schedule: October 2019

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:

reatom data flow

Installation

npm i @reatom/core

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

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.

Why not 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.

Why not 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

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

Why not 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...