Object.Observe spec was pulled from ECMAScript. Many people praised React/Redux as an escape from the Observable model. So generally, when people see "Observables", they tend to stray away, if not simply for the appearance of them falling out of popularity. How are MobX's Observables different? Why bring the observable model into the React ecosystem?
One of the core principles of Redux is that the state is read-only so that any updates to the state must occur in a simple function (reducer) that replaces the state rather than mutating it. This gives the organizational benefit of keeping all state management code in a concentrated place. Has this caused any drawbacks for understanding where and when the state might be updated since MobX allows for scattered mutations throughout an app? Is testing more difficult especially in complex applications that might be drawing data from multiple sources asynchronously? Also, would this account for extra ramp-up time for new members to the team? Thanks!
I struggle with React-Router and its nested routes concept. That's why I put visibility logic of dump components into smart components. URLs can contain some app state too. To me, it's difficult to maintain state in Routes and Stores.
On MobX docu
router is only mentioned but never shown.
What do you think about UI Routing? Is it time to move on and keep all the state where it belongs to, in a state machine/state manager like MobX/Redux?
You mentioned MobX 2.2 action decorator. Do you plan to have any method that will enable to "implement" actions outside of obervable as well?
I created an experimental model/wrapper around mobx and I am curious if I could use that feature as well (https://github.com/pvasek/mobx-app-model).