• Enzyme and tape / tape-runner (and faucet 😎)
• css modules / sass (but I think JSS is very interesting as well)
• cats :) but currently we don't have any as he/she would quickly become a toy for our toddlers

I travel each day by train to the office, so basically I work on MobX in the train (less then an hour per day) and also a bit during the evenings. But that differs a lot depending on how many other activities I have :)

At Mendix some teams are depending on MobX, but there is no team behind it. I do have several days a month to work on it though.

1. Play with it
2. Improve docs based on your experience / file feature requests
3. For minor improvements just create a PR, for bigger improvements discuss them in an issue first
4. Feel free to pick any open issues (make sure to mention that)
5. So far I have been blown away with a few PR's already that added really important improvements, like the dev-tools are largely the work of @Andy_Kogut

Interesting! Yes that should be no issue, action is just a higher order function that invokes and returns the value from the the wrapped function without signature changes.

For routing I try to resolve it somewhere in the root of the component tree, and just use it to update the view state of the application (like what is the current selection, or even page, etc). Then the rest of your application can become router unaware.

For updating the current url I always do one of the following:

1. just update it as part of your action, completely unrelated to mobx (for example when hitting a "login" button or something like that).
2. do it as side effect of a state change in an autorun, for example if the selection changes, see for example: github.com/mweststrate/mobx-contacts-list/blob/ma…

You're welcome :)

I think the following answer applies to this question as well: hashnode.com/ama/with-mobx-cinspo7i500vyxs53buh8e…

Visual Studio Code. I am a heavy typescript and (T/J)SX user, but I think it is an awesome IDE for normal javascript as well.

I hope that ES6 proxies will soon become mainstream (it is not yet available in Safari and some IE versions). A lot of code of MobX could then be thrown away. Making arrays observable was a very complicated task, and stills has limitations (like observable arrays not being real javascript arrays), which as it seems, could all be solved by ES6 proxies. So I'm eager to adopt it. Sadly it cannot be polyfilled, but yes, in a distant future I definitely would like to move to proxies.

Yes, I'm aware of at least ~5 companies that use MobX in production for complex projects as they contacted me about it in one way or the other. There are even some famous companies in there.

Node / Typescript / Webpack / React / Mongo / Postgresql / Xtend

I prefer SSR (Server Side Rendering). It is unambiguous and to the point :)

Yes, you can use mobx.map for this. With mobx.has you can observe not-yet existing properties

const store = map({test1: null});
autorun(() => {
  if (store.has("test2")
    console.log(store.test2);    
});
store.merge({"test2": "aaa"});

EDIT Object changes (including adding observables) can also be detected by using

const store = observable({test1: null});
mobx.observe(store, (change) => {
  if (change.type === "add")
    console.log("attribute " + change.name + " was added!")
});
extendObservable(store, { test2: "aaa" });

See also this answer

At Mendix we have a really complicated model (500+ classes, thousands of attributes, lots of inter data relationships). We have partners that write plugins that modify, analyze or generates these models. Independently we have partners that write visualizations. So we needed a system that was

1) simple to write (partners are often no full time JS devs) 2) highly performant 3) ensures consistency without needing to state data needs / force UI updates 4) CRUD actions and relations are very easy in MobX (no normalization needs etc)

I think the benefit of using MobX is that you have to learn way less concepts and it keeps your code more straight-forward. Since it is unopinionated about how you structure your data, it is more suitable to highly decouple state from components. In Redux your component structure and state structure are highly related each other, especially when performance matters. In MobX this is a lot less the case.

mobx-react already forbids currently to change the state inside the render function of a component. This is done internally through the function mobx.extras.allowStateChanges(false, block).

In the next minor version of MobX, 2.2, a new feature will be added: the action function / decorator can be used to wrap around all your actions. If you then run MobX in strict mode, it will throw on any attempt to mutate state outside of actions.

Efficiently snap-shotting state is possible and not too hard in MobX, as demonstrated in the demo of my Reactive2015 talk. A future version of MobX (or the devtools) will probably even have a standardized approach to this.

If you start to build undo/redo you will soon discover that undo/redo is often a lot more than just 'snapshotting'. Two other aspects play an important role in undo/redo: transactions (actions of a user might be consist of multiple smaller actions) and side effects (you don't want to undo just the client state, but also revert data that was already sent to the server).

So for that reason I would use snap-shotting as debug utility, but command apply / unapply if you need complex undo / redo patterns.

Hard question to answer, as so far I am quite amazed in which kind of applications it has been used for which I did never considered it, like webGL / canvas based stuff and such. But I think MobX shines when your domain model is highly interwoven with lot of CRUD like operations.

It makes less sense to MobX with systems that have a strong focus on event based, append-only mechanisms. This kind of applications are better suited by an immutability based approach. But I think that is a minority of the apps, most applications are about data entry and modification.

MobX started for two reasons: 1) existing state management solutions weren't fast enough 2) we wanted to write simple, straight forward code. Imho the project succeeded in both goals.

I touched the subject of performance shortly on the React Amsterdam conference, see this slide (video will appear soon) or this tweet with stats that compares performance with Redux.

In short: MobX very efficient; the number of observers is not influenced by the number of derivations, but by the number of active reactions (like, amount of visible components). Derivations will tend to go asleep if not used by some reaction. Fine grained observability allows for much more optimizations that coarse grained immutable state or manual subscriptions. Since in MobX subscriptions are under the hood, observers are not established by using callbacks, it is just a simple object pointer in an array. These things make it all very efficient.

There are a few people in the open source community that are familiar with the code base and have contributed bug fixes etc.

Besides that MobX plays an crucial role in the work of 3 development teams at Mendix. So although new features are mainly developed for the community (for example at Mendix we don't use babel transpilation or react native), Mendix will keep at least the lights on if I would be hit by a bus :).

Ha, every sentence a question :)

I think the freedom in organizing and managing state is both the strongest and weakest point of MobX.

Strongest because you can think about the structure and logic of your domain state completely independent of the rest of your app, and I believe you can achieve better decoupling of your state from the UI then with for example Redux.

It's also a weak point because MobX doesn't do anything to prevent your state structure to become a mess or scattering logic all over the place. I do believe domain logic should not be in components but MobX doesn't enforce it. Personally I work a lot with controller classes or model classes with instance methods.

MobX 2.2 partially addresses the mutations-from-anywhere issue by introducing actions: functions need to be decorated as actions before they are allowed to modify the state, so that you can clearly recognize them, and not modify state anywhere else.

Funny enough, I didn't hear anybody complain about not being able to trace where mutations came from. The simple reason for that is that derivations in MobX are always run synchronously (unlike similar frameworks!). So even if a derivation is triggered unexpectedly, you simply can find the causing mutation back in your stack.

Most people coming from Redux find working with asynchronous data is ridiculous easy in MobX. Testing asynchronous stuff is not significantly harder or easier then it is without MobX. You can for example use when(observable expression, effect) which is quite similar to a promise.

I think MobX is a lot easier to learn for new members than most other state management solutions. For two reasons, it allows you to use concepts developers many are familiar with, like references and classes. And secondly with MobX you can focus on a the logic around a small piece of domain model, without needing to know how it ties to the rest of the application, as the app should largely react to state changes automatically.

Observables are a very broad concept, and depending on the context they have a good or a bad name. Both the ES7 Object.observe and RxJS provide (different kind of) observables. Personally I'm happy that the ES7 proposal didn't make it, as the semantics where confusing at least. In MobX observables are really an implementation detail. In hindsight the @state might have been a better name for the decorator than @observable. Observability is a concept that is used internally by MobX to detect when stuff that can be derived from state is not consistent with the state itself anymore. When using MobX you shouldn't be bother anymore with wiring up and tearing down observable listeners. MobX abstracts away from exactly that. But since observables are used internally, MobX can establish very fine grained observers so that it can determine very precisely which derivations are out of sync. But in principle MobX is about reactivity, observability is just the means to get there, not a goal in itself.

An interesting difference with the ES7 proposal is that MobX observers are always triggered synchronously. This simplifies the semantics a lot and makes tracing and debugging easy; if you want to know why a derivation runs, just set a breakpoint and the stack will contain the change that triggered it. In the upcoming version the DevTools will even assist you in doing this.

Development started almost a year ago. It has been used since then at Mendix and we use it in a 40Kloc production system since roughly October as the central mechanism to manage state

When we started a green field project at Mendix, almost a year ago, i started with the question: how should the code look that we want to write. Because we knew our problem domain particularly well; hundreds of different domain object to be edited by hundreds of different editors. Knowing that we would have a lot of back and forth on the components. So we wrote pseudo code like:

class ProfileView {
   render() {
      return <span>{this.user.displayName} ({this.user.organization.name})</span>
   }
}

We didn't want to be bothered how things like displayName or even deep references like organization.name and would be kept in sync with the state. So from there on I started thinking how we could achieve the above. We figured that components need to detect themselves what data they use to be able to subscribe to it. That leaded to the whole observe and MobX thing. I think in the end we came pretty close to the above pseudo code :)

Initially the project was just an experiment with no real intent to open source it. So my 30-seconds name for the repo become Mobservable (contraction of mob and observable; a lot of observables). When I OSS-ed it, i figured that Mobservable wasn't really about an api for observing data, but about reacting to data. So I started looking for a new name and ended up with MobX: short, still relates to Mobservable, and the X hints to reactivity. The "Mob" can also refer to the mafia, which nicely conflicts with state management :-), and might be fun for a logo (which I never got to, so suggestions are welcome ;-)).