4 ms·

What are the downsides of MobX that you've come across? The main ones I've encountered are not being sure why something isn't reacting (always my fault but not

What are the downsides of MobX that you've come across? The main ones I've encountered are not being sure why something isn't reacting (always my fault but not always that easy to track down), odd interop issues with observables actually being "proxy" objects (e.g. useless console.log unless you call toJS), I guess no middleware-type concept or Saga type side effect management (never really used middleware in Redux and disliked all the ceremony around side effects)... that's all I can think of right now but curious to know others experiences. I honestly can't imagine any reason I'd go back to Redux aside from if it was used on a project I was working on though. I can develop so much faster and with fewer bugs (as typechecking MobX code thoroughly is much easier than Redux with Typescript) that there's no comparison, and like the OP, I think everyone should try it out - you'll almost definitely be pleasantly surprised!

aidos 9y ago
I've been working with it recently. The lack of prescriptiveness is an issue generally. No different from not having a library, but it's worth considering. The library itself works really well. Use strict mode and everything is super fast and reliable. Today we've been evaluating mobx-state-tree. It has some noise (not as bad as redux). It's opinionated which helps to remove architecture decisions. So far it looks promising.
- ng12 9y ago
  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.
  - aidos 9y ago
    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).
    - ng12 9y ago
      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.
      - aidos 9y ago
        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.

aidos 9y ago

I've been working with it recently. The lack of prescriptiveness is an issue generally. No different from not having a library, but it's worth considering. The library itself works really well. Use strict mode and everything is super fast and reliable. Today we've been evaluating mobx-state-tree. It has some noise (not as bad as redux). It's opinionated which helps to remove architecture decisions. So far it looks promising.

ng12 9y ago
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.
- aidos 9y ago
  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).
  - ng12 9y ago
    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.
    - aidos 9y ago
      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.