What's difficult about building an application? Obviously, you can do anything with plain, vanilla JS, but things start getting hairy when you try to keep the UI and the state of the application in sync. You call services, you get data. Data must be reflected in several places, HTML elements must be changed, added, or removed, and so on—this is where the complexity lies.

So far, we've been working only with state in components, and you could very well keep doing so: your top level component's state will include everything you need, and you'd be able to manage by passing everything you need as props to the components below. Of course, as your application grows, this won't scale very well. What's the tipping point? Redux is a tool to manage state, but its own developers suggest that you should use their package if and only if you fulfill the following conditions, and I quote from https://redux.js.org/#before-proceeding-further:

• "You have reasonable amounts of data changing over time."
  
• "You need a single source of truth for your state."
  
• "You find that keeping all your state in a top-level component is no longer sufficient."

Of course, these rules are not really precise, and allow for subjectivity, so there's no clear-cut point at which you'll have to use Redux. However, for most modern large scale applications, it's quite safe to say that Redux will probably come in handy, so let's assume that for the rest of this chapter.

In this recipe, we'll install Redux, and start to see how to work with it in React.