FLAXOM (work in progress)
State manager with a focus of all needs
Goals and features
- 🐣 simple abstraction and friendly DX: minimum boilerplate and tiny API
- ❗️ static typed: best type inference
- ⚡ performance: light tiny updates in huge state
- 📦 modular: reusable instances (SSR)
- 🗜 small size: 2 KB gzipped
- 🧪 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)
- synchronous glitch free: resolve diamond problem
- simple integration with other libraries (Observable, redux ecosystem, etc)
- awkward for write bad code
- handy for write good codeÍ
Description
FLAXOM 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.
Motivation
Why not redux
- Selectors are not inspectable (is lacking in devtools).
- Difficult static type inference (because every selector must to know full path to parent state).
- Hard for modular architecture (because every selector must to know about parent state).
- Separation of interfaces, to reducers and selectors, complicating build separated domains.
- Selectors - is manual API to state. It must be manualy described and memorized.
- Selectors execute after state change at subscriptions - error in selector will throw error and is no possibility (ok, all possible, but it is really hard) to restore previous valid state.
- classic reducer API is had much boilerplate and [static] type description boilerplate.
- Selectors "runtime" oriented, mean if some "feature" use any part of state (by selector) when you will remove that part, you get the error only when you will try to mount your "feature" at runtime (if you have not static typing). One of the solutions - is connect all features statically by imports.
- Middleware - is confound pattern that, sometimes unexpected, modify the behavior of store. Reference example: actions for redux-thunk don't logged.
A part of problems solves by various fabric functions, but without standardization it is harmful.
Why not effector
- Effector is about atomic stores - it statefull approach with problems:
- probable memory leaks
- difficult [store] instance reusability (for example, concurrences problems with SSR)
It can be solved, but better way solve it by design of library architecture and API
- Asynchronous and probably cyclic dependencies specification
- The weight can be smaller but it does not
- Throw in reducer is not cancel computation of other reducers
Why not MobX
- Huge bundle size, unstandardized foreground syntax (decorators), ES5 limitations
- Doesn't move to separate model and view.
- Runtime semantic and mutable state (is not a better way for debugging).
- Proxy pattern is lack of visual part of code semantic.
- Is not simple under the hood and it need to consider when choose algorithms for word with data-structure
- And others...
Next: