luhmann/hired

# 4. Mobx

Date: 04/04/2017

## Status

Accepted

## Context

* At the time of writing there are three predominant state-management solutions within the react-ecosystem: None/Internal,
Redux and MobX. While we probably could get away with using just internal state-management for the scope of this App,
a global state-management solution makes a lot of sense for future extensions of the app.
* "Time is the ultimate observable" as Michel Weststrate the developer of Mobx put it. Apps that deal with time are
well suited for an observable and reactive approach of programming. MobX is well suited for both criteria.
* Mobx is well suited to work with Typescript as it makes ample use of Decorators for cleaner code and offers a natural
concept of multiple stores for your state, which is a good fit for the more OOP-centric ideology of Typescript. The
MobX ecosystem from personal experience has better type support than the redux-camp.
* We are not that interested in how the UI got into its final state, it just has to be right. So we do not need the
level of evented control that redux offers.
* The developer team is small (a group of one), so we do not that much require the stricter programming style that redux
prescribes

## Decision

We are using MobX

## Consequences

* Think reactive
* Put your state mutations in an action.
* Be aware of the limitations within mobx-observables: https://mobx.js.org/best/react.html