51 ms·

So for people who think they need Redux, first read "You Might Not Need Redux" [0] by Dan Abramov himself, creator of Redux. Then also I would recommend MobX [

So for people who think they need Redux, first read "You Might Not Need Redux" [0] by Dan Abramov himself, creator of Redux. Then also I would recommend MobX [1] over Redux, it's easier to get started and in my opinion easier and better in general. [0] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.8eaaozi87 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx

ng12 10y ago
Correct me if I'm misunderstanding, but one thing that worries me about MobX is that it seems leakier than Redux. Something that I really, really care about is that a well-architected React application should hardly care what the data layer is. The bulk of the application is comprised of dumb/presenter components and only the handful of container components know anything about Redux. Things like this (from the docs) make me nervous: const TodoView = observer(({todo}) => <li> <input type="checkbox" checked={todo.finished} onClick={() => todo.finished = !todo.finished} />{todo.title} </li> ) TodoView is a dumb component that operates simple data passed via props, but now it needs to know that it's an observer and presumably rely on some facet of MobX to work?
- cheapsteak 10y ago
  You can easily maintain the abstraction of dumb components if you wish to: const TodoView = ({title, isFinished, onClick}) => ( <li> <input type="checkbox" checked={isFinished} onClick={onClick} />{title} </li> ) const TodoViewContainer = observer({todo} => ( <TodoView title={todo.title} isFinished={todo.finished} onClick={() => todo.finished = !todo.finished} /> )) But how often are you changing your app's data layer? Is the tradeoff _always_ worth it? Mobx allows you to be as pragmatic or dogmatic as you choose to be
  - ng12 10y ago
    > But how often are you changing your app's data layer? Is the tradeoff _always_ worth it? Yes, because in my mind that's the litmus test that your app is properly data-agnostic. And a key thing about Redux is it stays that way -- it's actually difficult to leak your data store to child components. Even if I adopt the above approach with MobX it'd be incredibly easy for some other developer to start passing around stores everywhere. My gut feeling is that MobX would be great for a personal project but doesn't scale that well.
    - gitaarik 10y ago
      I've had a presentation about this a short while ago. It's easy to do both ways with MobX. You can have smart components and dump components however you want them. You have this with Redux too, but the most standard way in Redux is to use connect() and that makes components dump anyway.
YPCrumble 10y ago
Completely agree about Redux - it has a large scope of functionality that also includes a long learning curve. I started using FreezerJS [0] a while back and have loved its simplicity. To my knowledge is the simplest alternative for state management, which you can understand in the ~100 line "Example" they provide. [0] https://github.com/arqex/freezer https://github.com/arqex/freezer
paol 10y ago
I'm 3 months into my first React/Redux project and wouldn't adopt Redux again if I were starting over. Don't get me wrong, it's not horrible, but it's not great either. Compared with the extreme elegance and simplicity of React itself, Redux is verbose, boilerplatery and the way it integrates with React never feels natural. I've taken a look at Mobx and had that aha moment of "yes, this is what the solution should look like!" Of course there's a big caveat here: not having really used it I don't know what its problems are yet. I'm comparing the real world warts of Redux with the platonic ideal of Mobx, but still it's definitely what I would try if I were starting a React project now.
- ng12 10y ago
  > the way it integrates with React never feels natural Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.
  - sixo 10y ago
    Not the parent, but when I was trying to learn R+R I kept getting confused by what they meant by 'state'. React state belongs to some component (whichever can mutate it) and is passed to children via props, and generally seems to include a mixture of view state and data/model state, with view-state originating somewhere in the component hierarchy while model state comes from the root. Redux's tutorial implied to me that it expected all mutable state to originate from the root, which clashed with what I had come to expect from React. Since I am fairly new to front-end JS, I just found myself confused at which way was really wiser.
    - trex654 10y ago
      This comes up fairly frequently. The honest answer is that it's up to you and the requirements of your app where state gets stored. Unfortunately, state is everywhere: server/database state, local storage/cookie state, redux store state, react state, DOM state, etc. And that's if you have a fairly standard setup. Sometimes you want info from redux store state also stored in local storage and pulled on page reload, sometimes you want to get state from the server before continuing, sometimes an external library insists on DOM state, etc. Generally, the problem redux is trying to solve is sharing state between components and saving client state globally. If there is information in a component for which you don't want to do either of those things, like UI details such as if a menu is or isn't collapsed, better to have that in the component react state. Though this can be murky also. Showing the error modal I put in the redux store because I want it to supersede all other modals and to work globally. This has been my experience anyway, as usual YMMV.
msoad 10y ago
I used both Redux and MobX. I can't recommend MobX enough. Redux is just way too much boilerplate code and has a steep learning curve. Also MobX + TypeScript is just beyond awesome! You don't want to do MobX without TypeScript if you have the chance.
flaviojuvenal 10y ago
It's been less than 6 months I first heard about Redux. Looking at its issues, it seems to be a little more than 1 year old. Now everyone is talking about MobX. Why not improving Redux in first place? If it's verbose, why not writing more abstractions on top of it to make it easier to use? IMHO we should think more about those questions before writing another framework-of-the-day.
- jorde 10y ago
  Mobx has been around for a while but it's just less well known due to developer relations. In my experience, Redux is great but requires a lot of work to get started, or abstractions. People have made quite a lot of open source projects to solve these issues for different use cases but it looks like Dan and other developers want to keep Redux core very simple so I would not expect any opinionated abstractions to land in the core. Mobx on the otherhand is "batteries included" and doesn't require much extra code to get started. We're using Mobx in production and only packages we needed to install were `mobx` and `mobx-react` along with some babel extensions. Very simple and increases developer efficiency by a mile not to mention onboarding time...
- gitaarik 10y ago
  The strategy of MobX is different. It's not easily possible to make Redux work like how MobX does it.
- acemarke 10y ago
  There's definitely a lot of abstractions being written on top of Redux. Some of them stay with Redux's conventions, others try to take it in a very different philosophical direction. My Redux addons catalog lists just about everything out there: https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links .

ng12 10y ago

Correct me if I'm misunderstanding, but one thing that worries me about MobX is that it seems leakier than Redux. Something that I really, really care about is that a well-architected React application should hardly care what the data layer is. The bulk of the application is comprised of dumb/presenter components and only the handful of container components know anything about Redux. Things like this (from the docs) make me nervous: const TodoView = observer(({todo}) => <li> <input type="checkbox" checked={todo.finished} onClick={() => todo.finished = !todo.finished} />{todo.title} </li> ) TodoView is a dumb component that operates simple data passed via props, but now it needs to know that it's an observer and presumably rely on some facet of MobX to work?

cheapsteak 10y ago
You can easily maintain the abstraction of dumb components if you wish to: const TodoView = ({title, isFinished, onClick}) => ( <li> <input type="checkbox" checked={isFinished} onClick={onClick} />{title} </li> ) const TodoViewContainer = observer({todo} => ( <TodoView title={todo.title} isFinished={todo.finished} onClick={() => todo.finished = !todo.finished} /> )) But how often are you changing your app's data layer? Is the tradeoff _always_ worth it? Mobx allows you to be as pragmatic or dogmatic as you choose to be
- ng12 10y ago
  > But how often are you changing your app's data layer? Is the tradeoff _always_ worth it? Yes, because in my mind that's the litmus test that your app is properly data-agnostic. And a key thing about Redux is it stays that way -- it's actually difficult to leak your data store to child components. Even if I adopt the above approach with MobX it'd be incredibly easy for some other developer to start passing around stores everywhere. My gut feeling is that MobX would be great for a personal project but doesn't scale that well.
  - gitaarik 10y ago
    I've had a presentation about this a short while ago. It's easy to do both ways with MobX. You can have smart components and dump components however you want them. You have this with Redux too, but the most standard way in Redux is to use connect() and that makes components dump anyway.

YPCrumble 10y ago

Completely agree about Redux - it has a large scope of functionality that also includes a long learning curve. I started using FreezerJS [0] a while back and have loved its simplicity. To my knowledge is the simplest alternative for state management, which you can understand in the ~100 line "Example" they provide. [0] https://github.com/arqex/freezer https://github.com/arqex/freezer

paol 10y ago

I'm 3 months into my first React/Redux project and wouldn't adopt Redux again if I were starting over. Don't get me wrong, it's not horrible, but it's not great either. Compared with the extreme elegance and simplicity of React itself, Redux is verbose, boilerplatery and the way it integrates with React never feels natural. I've taken a look at Mobx and had that aha moment of "yes, this is what the solution should look like!" Of course there's a big caveat here: not having really used it I don't know what its problems are yet. I'm comparing the real world warts of Redux with the platonic ideal of Mobx, but still it's definitely what I would try if I were starting a React project now.

ng12 10y ago
> the way it integrates with React never feels natural Could you elaborate on that? In my opinion Redux reinforces that the majority of your app should effectively be (props) => JSX (even if they're es6 classes, they're still just rendering props). Alternatively I feel like it'd be relatively easy to do non-Reactish things with MobX since more of your components are aware of it.
- sixo 10y ago
  Not the parent, but when I was trying to learn R+R I kept getting confused by what they meant by 'state'. React state belongs to some component (whichever can mutate it) and is passed to children via props, and generally seems to include a mixture of view state and data/model state, with view-state originating somewhere in the component hierarchy while model state comes from the root. Redux's tutorial implied to me that it expected all mutable state to originate from the root, which clashed with what I had come to expect from React. Since I am fairly new to front-end JS, I just found myself confused at which way was really wiser.
  - trex654 10y ago
    This comes up fairly frequently. The honest answer is that it's up to you and the requirements of your app where state gets stored. Unfortunately, state is everywhere: server/database state, local storage/cookie state, redux store state, react state, DOM state, etc. And that's if you have a fairly standard setup. Sometimes you want info from redux store state also stored in local storage and pulled on page reload, sometimes you want to get state from the server before continuing, sometimes an external library insists on DOM state, etc. Generally, the problem redux is trying to solve is sharing state between components and saving client state globally. If there is information in a component for which you don't want to do either of those things, like UI details such as if a menu is or isn't collapsed, better to have that in the component react state. Though this can be murky also. Showing the error modal I put in the redux store because I want it to supersede all other modals and to work globally. This has been my experience anyway, as usual YMMV.

msoad 10y ago

I used both Redux and MobX. I can't recommend MobX enough. Redux is just way too much boilerplate code and has a steep learning curve. Also MobX + TypeScript is just beyond awesome! You don't want to do MobX without TypeScript if you have the chance.

flaviojuvenal 10y ago

It's been less than 6 months I first heard about Redux. Looking at its issues, it seems to be a little more than 1 year old. Now everyone is talking about MobX. Why not improving Redux in first place? If it's verbose, why not writing more abstractions on top of it to make it easier to use? IMHO we should think more about those questions before writing another framework-of-the-day.

jorde 10y ago
Mobx has been around for a while but it's just less well known due to developer relations. In my experience, Redux is great but requires a lot of work to get started, or abstractions. People have made quite a lot of open source projects to solve these issues for different use cases but it looks like Dan and other developers want to keep Redux core very simple so I would not expect any opinionated abstractions to land in the core. Mobx on the otherhand is "batteries included" and doesn't require much extra code to get started. We're using Mobx in production and only packages we needed to install were `mobx` and `mobx-react` along with some babel extensions. Very simple and increases developer efficiency by a mile not to mention onboarding time...
gitaarik 10y ago
The strategy of MobX is different. It's not easily possible to make Redux work like how MobX does it.
acemarke 10y ago
There's definitely a lot of abstractions being written on top of Redux. Some of them stay with Redux's conventions, others try to take it in a very different philosophical direction. My Redux addons catalog lists just about everything out there: https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links .