Main
Reatom
#The ultimate state manager for any kinds of applications.
Key features
#- efficient and reliable reactive runtime
- minimal but powerful primitives
- advanced primitives to abstract away the complexity of asynchronous interactions
- rich official ecosystem with lots of high-quality helpers and integrations
- tiny bundle size starting from 2KB
- full TypeScript support
- nice debugging experience
- builtin DI for straightforward testing and SSR
- lifecycle hooks for describing focused and self-sufficient models
Getting started
#Read the docs or see examples.
FAQ
#Comparison
#Redux: Reatom was heavily inspired by Redux and does share many design principles with it. But it has many flaws that are hard or impossible to fix. Absence of action batching, non-atomic selectors and linear state update complexity, to name a few. Reatom solves all of them, implements much more features and reduces the amount of boilerplate code a lot.
MobX: MobX bundle size is too huge to use it in small embedded widgets, it uses getters/Proxies for change detections and has mutable nature, which eventually leads to confusing debugging sessions. It has no atomicity as well.
Effector: Effector encourages the description of sequential procedures through custom operators like sample, making the code really confusing. It also lacks the laziness of reactive computations, automatic dependency tracking, and is less performant compared to Reatom.
Solutions like zustand, jotai, nanostores, xstate, and many others, are either less efficient than Reatom, or are not that feature-rich.
What LTS policy is used and what about the bus factor?
#Reatom is always developed for continous usage. LTS versions are released once a year since December 2019 and have compatibility layers with the most recent version of the core package. We hope it proves our approach to maintainance to be responsible.
Our team currently consists of 4 people: @artalar and @krulod develop and maintain the core features, while @BANOnotIT and @Akiyamka help with documentation and issue management. Many other people also took part in the development of the library.
What about build targets and browser support?
#All packages are configured based on Browserslist’s “last 1 year” query. If you need to support older environments, you should handle transpilation by yourself.
Packages include CommonJS and ESM entrypoints. See package.json files for more details.
How performant Reatom is?
#Here is the benchmark of complex computations for different state managers. Although Reatom features introduce more overhead, it appears to be more performant than MobX, which is pretty impressive.
Limitations?
#No software is free from limitations, and Reatom is no exception.
- Immutable data introduces some overhead and encourages you to optimize your data structures.
- Lazy nature of Reatom may be unobvious and cause some problems like missing updates, but we find it much easier to bear with than the flaws of hot observables.
- Currently, there is no way to subscribe to errors of reactive computations, but we are working on it.
- Currently, there is no asynchronous transactions support, but we are working on it.
- We already have lots of utils and the ecosystem is growing all the time, but at the moment we don’t have a strict architectural framework like
mobx-state-treethat makes the development exceptionally straightforward.
Media
#Support the project
#Credits
#We really appreciate all contributors and free software maintainers. Shout-outs to the people behind the projects that helped us: