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-be4...
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.
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.
Sure, Redux strongly recommends that practise - and it's a good one - but nothing about it is specific to redux. You can factor your components in the same way with mobx, or with plain React for that matter.
The point of redux and alternatives is to remove state management from inside the components to a dedicated store. Redux doesn't feel natural to me because it does it in a round-about way, introducing more concepts than necessary for the job at hand. Then the responsibility for managing the store is scattered around the reducers, the actions and for anything not completely trivial, some middleware magic for good measure. The glue code between Redux and the components is slightly awkward as well.
Mobx just goes: a store is just a class with properties and methods. Done. Glue code? Wrap the component with a one-line decorator. Done.
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.
I've noticed that when programmers are introduced to a new technique there is a tendency to apply it everywhere. I had this experience when first learning recursion, it was all I used for a while, until I realized that was silly and now only use it where appropriate. This is true for OOP, functional programming, strictly adhering to even esoteric details of REST, etc.
I've found programming to be a lot like cooking. I really liked garlic, so when I first started cooking I would routinely add a couple extra cloves, until I discovered there very much was the possibility of too much garlic. This is true for each ingredient, you try stuff out and as your experience as a chef grows, you start to be able to suss out the right amount of each ingredient added at the right time.
Programmers are essentially virtual craftsmen, you have a set of tools and you try to build something effective with the tools you have. If you adhere to a principle so fiercely, the pieces of the puzzle often don't quite fit. You end up with a circle or square where something more acorn shaped would be most appropriate.
Anyhoo, don't take my word for it: "A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson or "Only a Sith deals in absolutes" - Obi-wan.
The Redux FAQ addresses this at http://redux.js.org/docs/faq/OrganizingState.html#organizing... . Note that a number of the linked comments regarding whether or not to use Redux come straight from Dan Abramov himself.
Also, I have a number of articles on React state management practices as part of my React/Redux links list, at https://github.com/markerikson/react-redux-links/blob/master... , which may help clarify some of the ideas as well.
Disclaimer: Cx is a commercial framework and I'm the author.
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>
)
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}
/>
))
Mobx allows you to be as pragmatic or dogmatic as you choose to be
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.
Also MobX + TypeScript is just beyond awesome! You don't want to do MobX without TypeScript if you have the chance.
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...