As I am sure you have heard a bunch of times, by now, React is the V in MVC. I think you can think of Redux as the M. Really, React + Redux kind of also act as the C.
So, you could just manage your state directly within your React components, and in a really simple app you probably should. However, if your app is going to have a lot of components with various states and likely some sort of user input/data retrieval, that is quickly going to become a pain to manage. This is where Redux can help.
If nothing else, read this section from the docs: http://redux.js.org/docs/introduction/Motivation.html It does a great job of explaining the why.
If Redux is not your thing, you can also check out Mobx. http://mobxjs.github.io/mobx/ Some find this a little easier to grok.
Hope this helps.
Redux and React solve separate problems, but those problems are often found "together" when building apps.
What React does is manage the "view" -- what elements are displayed on the page, what relationship they have to other elements, and what relationships that they hold to each other. In order to do that, React breaks up web pages into little modules called "Components." Each component can have a "component state," which is basically a big object that stores all your data. What's important to know about this object is that whenever you make a change to it, React is smart enough to know that it needs to re-render all the items that were using the information in the component state. That way, you can create apps that respond to user interaction without a whole lot of code.
Flux (of which Redux is an implementation) solves a different problem. Flux doesn't manage views at all, but like a Redux component, it manages the state of your application as a whole. It is designed to be a replacement for the traditional "Model-view-controller" framework.
Generally anything that requires you to use a database, query an API, etc, should probably be handled in a flavor of Flux. If you're just changing the view, you can get buy with just React.
As it turns out, it is possible to build out an application with a React front-end and not use Flux... we essentially built a model-view-controller application where React served as the view for our thesis project at MakerSquare... but Flux works with react because while they solve different problems, they solve those different problems in similar ways.
Redux is a particular type of Flux implementation that allows for a lot of really good features when it comes to debugging and logging, which is why people are raving about it. The learning curve is steep but plateaus -- once you get it, you start to realize why people tend to like it.
React shouldn't be responsible for data. It's View library. React components should hold self-related data (eg.: active, color, etc.)
Also, sometimes two or more components and perhaps something else might need same data - so you obviously cant store it in one component.
Redux, Flux and other *ux, solves all those problems.
Put simply, Redux acts as a store of state. A typical React app defines many different components. These components all require some state to be rendered correctly, e.g. the current user, what's being looked at, etc. Redux shares state globally across all the different components. Having centralized state reduces the complexity of managing the state transitions and makes access easier. Redux also implements the observer patterns, so consumers of state can be notified on state changes and rerendered.
state tree
single source of truth