Comparison
Looking Glass Engine began as a Freactal upgrade, but evolved into its own system; it uses RxJS under the hood and no longer depends on React or any view system to access state.
It badly wants to be used over Redux which is verbose and oblivious to the largely asynchronous nature of web transactions.
The update notification/subscription is straight RxJS, and it is easily interoperable with an RxJS update system, as it has a BehaviorSubject as its .stream property.
Like Redux
- LGE follows flux patterns
- Its actions mutate state
- Its state is injected into view
- All change is managed through actions
Like RXJS
- LGE is not tied to React features, versions or customs
- It is view-layer-agnostic
- It is synchronous by nature
- It is predictable and easy to test and observe
Like Saga
- It is async friendly
- you can call one method from another method
- because of this you can tell stories by tracking which sub-methods are called
Unlike Redux
- LGE is self-contained: all the views and state values are in a single file
- Actions are properties of a state sandbox, not scattered in include files
- A ValueStream can be tested or mutated with factory functions, not scattered and difficult to track or enumerate
- You can define field values and update actions in a single line.
- All the code is centralized to a single instance;
- Asynchronous handling is innate, not a third party addon with more ritual and caveats
Unlike RXJS
- LGE is concise, opinionated and centralized
- It is easy to write methods that update one or several streams
- Its documentation is under 5,000 pages
Unlike Saga
- You can watch individual values being updated. (Saga lets you watch the methodsthat change a valuebut it's not the same thing.)
- It uses OOP classical property/method metaphors
- Each collection is an independent, self-contained instance.
- Methods are clear sub-properties of a ValueStream, not detached from their names.
- You can use async functions without involved abstraction
There are a few features of LGE that are unique to all/most of these state systems:
Property Definition with Validation
Properties can be defined with simple (or not simple) validation to ensure that they are not fed bad values. Bad value attempts can be trapped and managed by observing to change.
Transactional Locking
Actions can be executed with transactional locking (in development). so that
- multiple changes trigger a single update
- errors reset state to its previous known value
Testable from the ground up
It is build with unit testing and as Stores are not buried in DOM, they can be tested by any unit test system without reference to the view layer.
Individual property change watching
You can subscribe to changes to individual properties through the watch method.