Reatom is declarative and reactive state manager, designed for both simple and complex applications.
- ๐ฃ 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.
Data flow diagram:
npm i @reatom/coreor
yarn add @reatom/coreimport { 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| Package | Version | Size |
|---|---|---|
@reatom/core |
|
|
@reatom/react |
 |
 |
@reatom/angular |
 |
 |
@reatom/observable |
 |
 |
@reatom/babel-plugin |
 |
- |
@reatom/debug |
 |
 |
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.
- 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 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
Aand derived sourceBandC, even if onlyBhas a subscribers and need to application workflow,Cstill 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
- probable memory leaks, because an store existents controlled not by a consumers (subscribers), but by a data sources, that is a more common.
- 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
- 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...
Follow us on Twitter @reatomjs
Telegram
- @reatom_en โ english
- @reatom_ru โ russian
- 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:
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!