3 ms·

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 deve

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

Lazare 6y ago
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. :)
- chrisweekly 6y ago
  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.
  - Lazare 6y ago
    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.
    - pknopf 6y ago
      It doesn't sound like the MobX author has any attention on supporting MST.
  - Epskampie 6y ago
    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.
brundolf 6y ago
> 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.
shams93 6y ago
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.
- brundolf 6y ago
  That kind of error would have nothing to do with MobX. Hard to say more without knowing the specifics.
pknopf 6y ago
Redux is king speg and boiler plater. So much work to do simple things, followed with advanced tricks to me the difficult things easier. I've used both extensively, MobX def wins IMO.
- three_legs 6y ago
  useState and useContext are better than both
asiachick 6y ago
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.
- brundolf 6y ago
  What I would do in that situation is: 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.
nsonha 6y ago
> 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.

Lazare 6y ago

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. :)

chrisweekly 6y ago
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.
- Lazare 6y ago
  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.
  - pknopf 6y ago
    It doesn't sound like the MobX author has any attention on supporting MST.
- Epskampie 6y ago
  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.

brundolf 6y ago

> 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.

shams93 6y ago

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.

brundolf 6y ago
That kind of error would have nothing to do with MobX. Hard to say more without knowing the specifics.

pknopf 6y ago

Redux is king speg and boiler plater. So much work to do simple things, followed with advanced tricks to me the difficult things easier. I've used both extensively, MobX def wins IMO.

three_legs 6y ago
useState and useContext are better than both

asiachick 6y ago

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.

brundolf 6y ago
What I would do in that situation is: 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.

nsonha 6y ago

> 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.