7 ms·

Mobx is an alternative. Simple and less boilerplate.

optimatex 9y ago
There is not goodness or evil. There are the variant tools for accomplishing variant tasks. I tried to use Redux, but I didn't recognize how to easily build scalable apps. At the same time, I performed the task with mobX, really easy and with zest. But this is my case. You can get an opposite result
joshuahutt 9y ago
An underrated alternative, at that. I had a great experience transitioning from Redux to MobX.
tomduncalf 9y ago
This! I feel like a broken record the amount of times I urge people to try MobX, but genuinely I think everyone I know who has tried it has been so pleasantly surprised at how quick and easy it is to work with and use effectively, compared to Redux. Personally, I reckon I can build stuff out which uses a reasonable amount of state at least twice as fast with MobX, and the code feels more maintainable as there's less of it, which as a freelancer is huge. That's not to say Redux is bad or there is no value to learning it though. It presents a really interesting take on state management and really opened my eyes to a huge amount of concepts. I'm just not sure I would want to go back to a heavy Redux project again having used MobX!
te_chris 9y ago
This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.
- hesarenu 9y ago
  The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.
  - CuriousSkeptic 9y ago
    Mobx vs redux is probably not the right comparison here though. Mobx comes bundled with 'computed' and encourages most state to be handled there. Redux doesn't have this, instead libs like reselect fills space. My experience with redux was frustrating in the way you explained, but once I "got" how to defer all state to reselect instead of trying to do things with reducers it got significantly simpler.
    - hesarenu 9y ago
      My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.
      - acemarke 9y ago
        The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at https://github.com/markerikson/react-redux-links/blob/master/project-structure.md https://github.com/markerikson/react-redux-links/blob/master... .
        hesarenu 9y ago
        I have done both approaches, ducks, slight variation on ducks all running on production apps. Still not satisfied. I have referred your links. Thank you btw.
- mweststrate 9y ago
  > I look at mobx I get reminded of.. Looking like, and being like are two different things :) Mobx reminds people (rightfully) of Meteor, Knockout, Angular etc, but when working with it you will see it is quite a different best. Just like Redux will remind people of flux, but that doesn't mean people shouldn't try Redux because e.g. Facebook Flux didn't work out.
- Lazare 9y ago
  > they're both very different Yes, but they exist to solve very similar problems. > when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. You may find it feels differently in practice. Because when I look at redux, I get reminded of managing crazy state trees in redux, and why I went to react/mobx in first place. :) To be sure, Redux has strengths too, and there are tradeoffs. But I don't think that a brief "mobx looks like ember!" really conveys much, and I think the number of people who have been happy after switching from redux to mobx further undercuts such easy dismissals.
- cloverich 9y ago
  It deserves to be first, because most people jump into redux because it seems like you're supposed to use it. Also I don't think I agree with the claim that they are very different. In theory, yes. In practice, I use it to solve the same problems in generally the same way (action driven updates, one-way data flow rendering), but with less boilerplate and (for my use cases) better performance. YMMV is fair, but anyone doing serious react work should be at least familiar with both.
  - ng12 9y ago
    But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.
    - cloverich 9y ago
      > But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying, and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.
      - ng12 9y ago
        You'd have a point if the article was intended for people trying to bootstrap a React stack but this is specifically a deep-dive on Redux. It's equivalent to people proselytizing Rust in any thread that mentions Go. Believe it or not some of us are not ignorant -- we know what MobX is and still choose Redux every time.
        cloverich 9y ago
        Actually it's a response to a response about using libraries to help with redux boilerplate. Depending on your scenario, mobx might reduce your boilerplate and your dependencies at the same time. That's absolutely appropriate context. And again while I appreciate not wanting to see those comments if you already know about mobx, not everyone does. I didn't. And I'll forever appreciate running into those comments myself. This isn't a go rust comparison (languages designed for different problems) -- it's a discussion about state management in a ui. I'm sure mobx won't be the only alternative brought up. Thats IMHO a good thing.
robmcm 9y ago
Redux is an alternative. Easy to reason about and debug.
deleted 9y ago
[deleted]

There is not goodness or evil. There are the variant tools for accomplishing variant tasks. I tried to use Redux, but I didn't recognize how to easily build scalable apps. At the same time, I performed the task with mobX, really easy and with zest. But this is my case. You can get an opposite result

joshuahutt 9y ago

An underrated alternative, at that. I had a great experience transitioning from Redux to MobX.

tomduncalf 9y ago

This! I feel like a broken record the amount of times I urge people to try MobX, but genuinely I think everyone I know who has tried it has been so pleasantly surprised at how quick and easy it is to work with and use effectively, compared to Redux. Personally, I reckon I can build stuff out which uses a reasonable amount of state at least twice as fast with MobX, and the code feels more maintainable as there's less of it, which as a freelancer is huge. That's not to say Redux is bad or there is no value to learning it though. It presents a really interesting take on state management and really opened my eyes to a huge amount of concepts. I'm just not sure I would want to go back to a heavy Redux project again having used MobX!

te_chris 9y ago

This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.

hesarenu 9y ago
The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.
- CuriousSkeptic 9y ago
  Mobx vs redux is probably not the right comparison here though. Mobx comes bundled with 'computed' and encourages most state to be handled there. Redux doesn't have this, instead libs like reselect fills space. My experience with redux was frustrating in the way you explained, but once I "got" how to defer all state to reselect instead of trying to do things with reducers it got significantly simpler.
  - hesarenu 9y ago
    My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.
    - acemarke 9y ago
      The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at https://github.com/markerikson/react-redux-links/blob/master/project-structure.md https://github.com/markerikson/react-redux-links/blob/master... .
      - hesarenu 9y ago
        I have done both approaches, ducks, slight variation on ducks all running on production apps. Still not satisfied. I have referred your links. Thank you btw.
mweststrate 9y ago
> I look at mobx I get reminded of.. Looking like, and being like are two different things :) Mobx reminds people (rightfully) of Meteor, Knockout, Angular etc, but when working with it you will see it is quite a different best. Just like Redux will remind people of flux, but that doesn't mean people shouldn't try Redux because e.g. Facebook Flux didn't work out.
Lazare 9y ago
> they're both very different Yes, but they exist to solve very similar problems. > when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. You may find it feels differently in practice. Because when I look at redux, I get reminded of managing crazy state trees in redux, and why I went to react/mobx in first place. :) To be sure, Redux has strengths too, and there are tradeoffs. But I don't think that a brief "mobx looks like ember!" really conveys much, and I think the number of people who have been happy after switching from redux to mobx further undercuts such easy dismissals.
cloverich 9y ago
It deserves to be first, because most people jump into redux because it seems like you're supposed to use it. Also I don't think I agree with the claim that they are very different. In theory, yes. In practice, I use it to solve the same problems in generally the same way (action driven updates, one-way data flow rendering), but with less boilerplate and (for my use cases) better performance. YMMV is fair, but anyone doing serious react work should be at least familiar with both.
- ng12 9y ago
  But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.
  - cloverich 9y ago
    > But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying, and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.
    - ng12 9y ago
      You'd have a point if the article was intended for people trying to bootstrap a React stack but this is specifically a deep-dive on Redux. It's equivalent to people proselytizing Rust in any thread that mentions Go. Believe it or not some of us are not ignorant -- we know what MobX is and still choose Redux every time.
      - cloverich 9y ago
        Actually it's a response to a response about using libraries to help with redux boilerplate. Depending on your scenario, mobx might reduce your boilerplate and your dependencies at the same time. That's absolutely appropriate context. And again while I appreciate not wanting to see those comments if you already know about mobx, not everyone does. I didn't. And I'll forever appreciate running into those comments myself. This isn't a go rust comparison (languages designed for different problems) -- it's a discussion about state management in a ui. I'm sure mobx won't be the only alternative brought up. Thats IMHO a good thing.

robmcm 9y ago

Redux is an alternative. Easy to reason about and debug.

deleted 9y ago

[deleted]