MobX is possibly my favorite open-source project. The elegance with which it makes an entire problem-space just disappear, with minimal magic or surprises, with maximal performance, with a delightful user-experience, with minimal opinions or assumptions about how you use it. I have nothing but praise; React + MobX is the most productive I've ever been while working on user interfaces.
On top of all that, Michael is a very reasonable and patient project leader. His documentation puts advanced concepts in plain terms, and when people file feature-requests he always displays a genuine willingness to consider their use-cases and points of view, to solve their problem if it's reasonable for the project to do so, and is never condescending even when questions or suggestions are plainly bad.
I have mostly found it to be a footgun and inspiration to write spaghetti. While it may have good intentions, it doesn't matter if it lets less experienced developers do absurd things that I now have to refactor. I don't think it really fits well into the React model, and while it's not only used for React, it's quite common that way
> I have mostly found it to be a footgun and inspiration to write spaghetti. While it may have good intentions, it doesn't matter if it lets less experienced developers do absurd things that I now have to refactor.
I admit the only team I've used it on consisted of three people, and there are certainly really gnarly things you can do with it if you go out of the way to, so I don't know how it scales to larger teams. Though I would argue that it encourages best practices by making those the paths of least resistance. I would also say that - unlike, say, RxJS - its mental model is very simple and straightforward, and should be quite accessible to inexperienced developers. But yes, it doesn't do a lot to stop you from shooting yourself in the foot.
> I don't think it really fits well into the React model
I disagree with this part completely. It doesn't fit well with the Redux/hooks model, but that's because it replaces it. In my opinion it lets React focus on what it does best: updating the DOM to match a new virtual DOM, and takes everything else out of React's hands, which to me is a huge win. I am not a believer in the "every state change replaces the entire root state structure using a composition of pure functions" model; I think it's contrived, clunky, and hard to follow. I believe that state should be minimal, but should be treated as what it is. MobX gives you all the tools you need to enshrine state as state, without introducing any duplication/synchronization complications.
My experience has been the reverse. I've found MobX code easier to maintain than equivalent Redux code, and although it's obviously subjective, I feel it is a good fit for the React model.
Just noting that experiences may differ sharply. :)
Same. I found MobX to be easier to reason about than Redux. I'd really like to give MST (mobx-state-tree) a closer look, too. MWeststrate is a "gentle giant" of sorts, and the idea of leveraging his more-opinionated framework resonates.
I’ve tried to use MST, but found it quite hard and contrived to use. I’m sticking with regular mobx for now, which I absolutely love. Since MST seems to be looking for maintainers I’m inclined to think it’s the best choice.
If you really need the (complex) functionality of MST, redux might be a safer choice going forward in that case.
I've used MST on a project and it was everything I'd hoped. Obviously one project isn't a lot of data, but I'd certainly use it again if another opportunity arose.
I found this as well. As an example (probably just bad coding on my part) I tried to use mobx to track preferences for a photo viewer, every photo then looked at the preference state from mobx. App slowed to a crawl because 300 photos are going through a few hundred lines of code each just to see if `showDate` is true/false and because `showDate` is "reactive" there's a whole ton of overhead it tracking that each photo is watching it.
Now of course I moved the code that looks at that state up the tree and then pass it down to solve but that kind of defeats the purpose of using it in the first place. The upper components should not have to care directly about data for lower components.
1) If all 300 photos aren't actually visible, make sure React skips actually rendering them (calling their render functions)
2) If they do all need to be visible, and they do all need to update in real time in response to that preference, consider adding a paging mechanism so that not as many are visible at once
You have to step back to the root question: do you want all of those components to visibly update immediately in response to that change? If not, make sure they don't try to. If yes, MobX is accomplishing that in the most efficient way possible so you may need to rethink your UI.
> I moved the code that looks at that state up the tree and then pass it down to solve
This doesn't really make sense to me as a fix, and to be honest I suspect it's merely covering up the problem in a roundabout way.
> a footgun and inspiration to write spaghetti. While it may have good intentions, it doesn't matter if it lets less experienced developers do absurd things that I now have to refactor
isn't it everything? My exp in redux is the same. Mobx however doesn't pretend to be for smart people and doesn't encourage them to invent a bunch of weird conventions like redux. I've never had any problem with state management, react solved it for me already. What I need a library for is a clear pattern for where to put domain code (again is it reducer or saga/thunk?) and never think about the library again.
Yeah its being used in a project I'm working on and basically is a major footgun. Also not every browser native api works well with it like I was expected to use this with p2p webrtc but it gives out weird "that function does not exist" errors when calling a method from another method.
> React + MobX is the most productive I've ever been while working on user interfaces
I loved using React/Inferno + MobX too.
Right now I find myself being much more productive with Svelte which already includes a reactive primitive out of the box (writable/readable) that can be used with classes too.
I haven't tried Svelte, but I've heard good things. I am curious how it handles reactivity beyond just the UI; the way you can use MobX's computed values for any arbitrary memoization layer is one of my favorite features.
AFAIK Svelte doesn't have memoization because, unlike React, it does't really need it. Svelte tracks reactive dependencies at compile time so that only the necessary parts of the DOM are updated when some state changes.
Svelte has a derived reactive store similar to a computed value in Mobx:
In Svelte you can define a reactive statement (or block) with the $ label syntax. It's semantically the same of a MobX's computed value, expressed succinctly `$: v = expr` where expr will be rerun when and only if its dependencies change.
I think you're being sarcastic, but my praise is genuine and not exaggerated. I've seen people express similar praise for projects like Clojure; sometimes you just find something that solves your problem so perfectly that you can't help but go on about it.
It has two key aspects that are very magical: the use of Proxy, and the way "tracked functions" work. But both of these, if you take the time to learn, are not very hard to understand. And once you do, everything else very straightforwardly and non-magically falls out from that. These two bits of magic also don't have many caveats/leaks, so in practice you usually don't have to think about the way they're implemented and can just work with the abstraction.
Compare this with frameworks like Aurelia that bring in piles of new, implicit, inscrutable abstractions in order to accomplish roughly the same thing. Sprawling magic, that you find yourself constantly tripping over left and right.
I'd counter: the right level of abstraction. If you have complex views that rely on a variety of properties, and you want performant updates, mutable change tracking automates the process of making it work at precisely the right level. The problem space that goes away is, in redux terminology, the need to make custom selectors as a performance optimization. Instead, you access the properties you need in your render functions, using vanilla js syntax, and mobx tracks it for you.
On top of all that, Michael is a very reasonable and patient project leader. His documentation puts advanced concepts in plain terms, and when people file feature-requests he always displays a genuine willingness to consider their use-cases and points of view, to solve their problem if it's reasonable for the project to do so, and is never condescending even when questions or suggestions are plainly bad.