npm i rxdeep
▷ Create a state object:
▷ Listen to changes on
'name' property of index 1 on the list:
_state.sub1.sub'name'.subscribeconsole.log; // --> logs `Jack`
▷ You can modify the top-level state:
_state.value = ; // --> logs `John`, since `John` is index 1 now
▷ Or mid-level states:
_state.sub1.value =; // --> logs `Josef`
▷ Or another sub-state with the same address:
_state.sub1.sub'name'.value = 'Jafet'; // --> logs `Jafet`
▷ RxJS interop:
;;interval1000.pipemap.subscribe_state.sub1; // --> logs `Jarvis #0`, `Jarvis #1`, `Jarvis #2`, ...
;_state.sub1.pipedebounceTime1000.subscribeconsole.log; // --> debounces changes for 1 second
RxDeep is completely framework agnostic. It is also by no means limited to use on frontend (though that is understandably most common use-case). Due to it being based on RxJS and having high interop with it, you can easily use it anywhere that you can use RxJS.
Because of its precise change emissions, using RxDeep in conjuction with popular UI frameworks should actually speed them up (since it results in less burden for the underlying change detection mechanisms of these frameworks).
RxDeep is not necessarily a replacement / alternative to many existing state management libraries. Typically these libraries provide / enforce some particular patterns which might or might not be useful to a particular application, while RxDeep avoids any such constraints, instead focusing on providing a performant and precise reactive state tree.
Here is how RxDeep compares / relates to some of the most well-known state management libraries:
Redux is a particular state management pattern (and a library providing it), while RxDeep is not. You actually can implement the Redux pattern using RxDeep state-trees if you so choose to.
Redux as a library doesn't have a concept of precision, i.e. you cannot listen to changes on a particular part of the state-tree in isolation. This is simply because Redux was designed primarily to be coupled with React, and so delegates figuring actual scope of changes to its Virtual DOM mechanism.
In contrast, precision is the main feature of RxDeep, which means surgically precise changes reach the final UI layer. With RxDeep the scope of each change is computed much more efficiently on the data layer (on the state-tree itself), instead of it being passed down to some external underlying library.
RxDeep and MobX share some core design philosophies in terms of being unopinionated reactive state management solutions. The main difference is MobX's implicit approach for automatically deducing state / expression dependencies, while RxDeep relies on the power of RxJS for explicitly defining / manipulating streams.
This brings much more fine grained control and extensibility, at the expense of face-value learnability (as RxJS does seem more complicated to newcomers). However in practice MobX syntax (e.g. computed values), doesn't differ much from the equivalent RxJS syntax (e.g. the map pipe). In fact, MobX's implicit deduction approach raises implicit constraints and considerations, while the explicit approach of RxJS avoids that, and the actual added complexity of RxJS kicks in for operations beyond the scope of MobX.
Amongst mentioned libraries, RxDeep shares most concepts and ideas with Focal. Focal, however, is specifically designed specifically to work with React, while RxDeep is completely framework agnostic. This also means that similar to Redux, precision is not a priority for Focal, while it is the main focus of RxDeep.