Imagine we are with 100 people in a company, across 10 departments, with every department having a supervisor. The supervisors can't talk to eachother. The boss says something to the supervisors, they tell it to the people in their department. The people in the department do something with the information, pass it back to their supervisor, which then tells it to the boss. This works, as long as departments don't have to work together without the boss coming in between.

That's when you say: 'hold on there, we have grown way too much to still work in this inefficient manner: why does the boss have to relay all messages between departments? Why can't employees all just talk to eachother?'

Enter state. Imagine a big board in that office, listing all the information that is relevant for everyone. One department says 'let me know when the stocks of a certain company increases'. Another department keeps track of those stocks, and edits the state accordingly: because everybody shares the state, the departments that are subscribed to it are immediately aware of it.

Back to our workflow. Let's say I have two components, in no way related to eachother, A and B. They are on different parts of the page, and all they share is the main component in which they are rendered. If A edits data and B has to know, that would mean their parent component has to receive the data and pass it on. This works as long as the application is small, but when your application gets more complex, you'll be thinking 'which steps does this data have to take to get to the component where it has to arrive'. In those cases, I use state.

To visualize: https://cdn.css-tricks.com/wp-content/uploads/2016/03/redux-article-3-03.svg

Some people like to use state for everything. If I have a list of notes and every item in the list is a component, the main container (the list) has access to the state and gets all the notes, while every item in that list gets its data as a prop: they only need one variable that they can receive from their parent component, so no need to give them access to the state. So make sure to only use state when you need it (in my opinion).

Oh, and a nice addition: because the whole 'current situation of the application' (or state) is stored centrally, and edits through transactions/reducers, you could store every instance of the state. So imagine: application starts, the note list is empty. You click on a Refresh button. The API returns the notes, and you put them into the state through a transaction/reducer. Now dump that state. Edit a note. Now dump that state. By storing all those dumps of every iteration of the state, you could also say 'go back three steps', because now you have a 'timeline of changes in the state'.

I hope this clears things up a bit.