I think this is why the MobX fanboyism irks me so much. It's a great little library but it does not solve the problems I have. I want to enforce the smart/dumb paradigm, I want to be able to quickly grok app state and monitor updates, I want nice dev tools, I want the data to be separated from components to the highest degree possible, I want to persist/restore complex app state. All of these are fundamental talking points for Redux and largely unnacounted for by MobX.
If all you switched to MobX just to avoid the boilerplate you didn't need Redux in the first place.
Well, the main reason for using these libraries is to automatically drive react. You want it to be easy to change your state and have that mirrored in the interface.
Mobx helps with much of what you've asked for above. Mobx-state-tree will give you even more from that list. Personally I think the persist/restore goal (and time travelling) is overrated (though mobx-state-tree will give you those).
It does not give you more from that list. MobX is, by design, non-prescriptive about who's touching your stores, how they're being passed around, how they're being updated, or how the API of your store looks. It's all fine if you have one or two developers but is a dangerous thing for large teams.
Have you used Redux's devtools? I wouldn't give those up for anything. Not sure if MobX has anything comparable.
I have used them, yeah. Mobx-state-tree (MST) can be wired directly to the redux dectools.
The strict mode in mobx ensures that stores can only be updated via actions, so you can restrict updates from that point of view.
On the flip side - mobx makes it dead easy to minimise your core state and transform it efficiently (and declaratively) for use in the front end (or wherever). I'm told reselect helps that use case now, but you'd be hard pressed to do a better job than mobx in that regard.
Personally, I found that my code was too obscure with redux. In implementing our login flow (it has more paths than most), I found that it was hard to see the real code between the architecture.
As ever, it's important to evaluate these tools critically to see where the fall down (which is what I've been doing with MST today). Too often people evangelise their product of choice while hiding the areas in which it's weak.
And to play devils advocate, redux will have you push a lot of code into middleware where people are left to do all sorts of crazy - it's not all the rosy enlightened path :-)
One of the things that pulled me to MST was that I couldn't see a simple way of managing cross-cutting concerns with my mobx architecture. MST (and redux) make that dead simple.
If all you switched to MobX just to avoid the boilerplate you didn't need Redux in the first place.