3 ms·

I'm curious what makes it bad on large projects.

• brundolf 6y ago
  In my experience with MobX, reactions that mutate observables (which triggers other reactions) can quickly get out of hand and become hard to debug if you're not careful. But doing this is also a huge code smell, and expressly stated as such in the docs, and even though it's necessary every once in a while, it's very possible to keep it under control to where it doesn't become a problem even in quite large projects.
  • Gehinnn 6y ago
    We put a facade on top of mobx that requires every autorun, reaction and runInAction to be named. Of course, updates outside of transactions are forbidden. This makes even complex applications debuggable!
  • machiaweliczny 6y ago
    That's why it should be forbidden by default. But if you use 1 way flow (events -> store -> ui) then MobX is great.
• cameldrv 6y ago
  If you thought goto was bad, observers are basically a comefrom statement. You change something and literally anything can happen. Once code starts getting large, these will start causing chain reactions and the code gets hard to reason about.
  • brundolf 6y ago
    The goal is for nearly all of your observers to be nothing but a cache-clear on a pure function ("computed", in MobX's case). Chained reactions (reactions that trigger other reactions) are very rarely necessary and should be kept to a small enough number that you can model the entire state-graph in your head.
    • spion 6y ago
      MobX works well when paired with a Rx-like library for the more complex cases. With that its never necessary to chain reactions.