[tomduncalf]

Been using MobX for about three years and I think it is wonderful. Incredibly easy to use (mark your variable as observable, modify it like you would any normal variable, and any components which use those variables in their rendering and are marked as observers automatically update), very performant out of the box (only components affected by a change re-render so no shouldComponentUpdate needed) and some excellent features like computed variables for derived values which automatically update. I really urge everyone to try it out. There is the odd time when the abstraction us a bit leaky (e.g. working with arrays is a bit different to plain JS) but with proxies in MobX 5 this is much improved.

I started out with Redux and I do think it’s worth learning - not just because it’s so widespread, but the concepts behind it are worth knowing and have influenced the way I design some stuff, but I found it really verbose and slow to work with compared to MobX (and more error prone) - there probably are libraries that help with this.

React Hooks look interesting for more simple use cases but I expect I’ll stick with MobX for the foreseeable future.

[kecupochrenx]

Try mobx-state-tree. It's basically MobX with Redux-like tree structure written by the guy who did MobX. It combines best of both worlds. We use it at work and it's just such pleasure to work with, highly recommend

[yayr]

It is indeen wonderfully easy to work with. However, it has some performance penalties. I found typescript in conjunction with pure MobX just as efficient.

Especially complex state de-/serialization is a breeze with serializr.

[tomduncalf]

Yeah exactly, for my use case (mobile device, frequent state updates) I couldn’t justify the overhead of state-tree after doing some profiling. Shame as it looks great and would have been a good fit ofberwise.

Thanks for the pointer to serializr - I hadn’t seen that before!

[oliverx0]

I second this. I am surprised it is not more popular.

[ychetyrko]

There is a new alternative to MobX/MST - Reactronic:

https://github.com/Nezaboodka/reactronic#readme

It is transactionally reactive state management library for JavaScript. Key difference from MobX/MST is that Reactronic doesn't enforce developers to stick with MST rules of building the structure of state - the state can be a set (graph) of usual JS objects.

Also, Reactronic has minimal set of concepts, just three: State, Transaction, and Cache. So, it is easier to use.

Drawback is that it's a new thing and is not yet battle tested.

[rjdlee]

I have a few months of experience working with MobX and have read a lot of the community material. Since it's so flexible, there's a lot of different patterns you can do with MobX. I haven't been able to set on one, any suggestions?

[tomduncalf]

The pattern I use is to create classes for stores, each store having a small, fairly well defined scope e.g. AuthenticationStore. These stores contain the observable variables, computed variables and action methods (I use strict mode) for working with the data. I allow the action methods to do other stuff like make HTTP calls etc too, I find life much easier that way rather than all the side-effects middleware hassle with Redux :)

I then use the “root store” pattern from the MobX docs (https://mobx.js.org/best/store.html) - I have a stores/index.ts file which contains a class containing instances of all the other top level stores. I can then instantiate the root store and access it either through Provider or as a singleton. Each store can have the instance of the root Store passed in to the constructor for cross-store communication, which can be convenient although I think other patterns such as callbacks are probably more architecturally sound.