JavaScript for Line of Business Applications

MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). The philosophy behind MobX is very simple:

Anything that can be derived from the application state, should be derived. Automatically.

which includes the UI, data serialization, server communication, etc.

MobX is inspired by reactive programming principles as found in spreadsheets. It is inspired by MVVM frameworks like in MeteorJS tracker, knockout and Vue.js. But MobX brings Transparent Functional Reactive Programming to the next level and provides a stand alone implementation. It implements TFRP in a glitch-free, synchronous, predictable and efficient manner.

State management within Angular started out as a single celled organism if you will in the form of a single controller managing all the state for the application. If this is a single page application, one controller makes sense right? We emerged out of the ice age by starting to group our views and controllers into smaller, self-contained units either within a directive or a route. This was a vast improvement, but there was still the problem of managing complex state within our applications. It was not uncommon for us to have bits and pieces of state strewn across our application tucked inside of controllers, services, routes, directives, and occasionally, in our templates. Mutable state in itself is not inherently evil but shared mutable state is a recipe for disaster.

I really like Cycle.js. It is simple and declarative. But it has two caveats. First it has hard RxJs dependency and that is too much: if I select a rendering library then I don’t want it to constrain my state handling! Second, Cycle’s DOM event subscription system is not practical (regardless how functional and “reactive” it may be): the emitted data must be encoded into DOM (e.g. by using data attributes like data-id=”myId”). Just ugly.

Single source of Truth. And its problems

The state of your whole application is stored in an object tree inside a single store.

That is a direct quote from Redux website. The most of the current Flux libraries use combined reducer and this has locked the developers’ mindsets to the fact that the state should be like a mega sized “blob” which is passed to the “dummy” components via props. And there is always an explicit layer which separates the state handling and the UI: the top level “application container”. Perhaps you’ve seen this kind of lines in Redux apps...