Background and Component state

Sometimes the UI code that a Component generates needs to change after the initial render (e.g. in response to a user interaction or network request). To enable these dynamic UI’s, React gives us Component state. Component state is an extremely useful and well-designed feature, but when used incorrectly, allows us to create brittle Components that are a nightmare to maintain, reuse, and test.

The problem

The problem arises when we attempt to use Component state to manage the state of an entire application. In real-world apps, certain types of state need to be shared between Components. A common example of this is authentication state, because many different Components of an app need to know if a user is logged in and who that user is. Let’s consider two components in an imaginary application: <UserMenu />, a dropdown user menu that lives somewhere in the nav bar, and <LikeButton />, a button somewhere in the body of the page that allows a user to like a post. Both of these components need to know who is logged in. It is possible to share the user data between these two components by keeping it in a parent's component state, e.g. <App />, and passing it down through the component hierarchy as props. Unless an application is extremely small or mostly stateless, this becomes a headache very quickly.

When we take the shared component state approach, we end up creating large quantities of "pass-through" props, which do little else other than shuttle along data and clutter up all the components in between. On top of that, the end users of these pass-through props (UserMenu and LikeButton) end up with a large prop surface area. In order for them to render, their parent must supply them with the many props that they need.

Components that require many props are more difficult to reuse. (<LikeButton /> vs <LikeButton loggedIn={this.props.loggedIn} username={this.props.username} likePost={this.props.likePost} />). All those props have to be typed out every time we want to use a LikeButton. This problem becomes even worse when testing a component, as each function and piece of data passed into a Component as a prop may need to be mocked when being tested.

Things get even more messy when a Component needs to change the shared component state. Imagine this: <App /> passes an onLike callback through the component hierarchy down to <LikeButton />. When a user clicks the button, <LikeButton /> makes a network request and then calls onLike. The callback calls setState on <App /> to record the change to the shared state. This type of arrangement creates complicated relationships between components that are very difficult to understand and change.

How Redux helps

With Redux, all of our data lives in a single Store, and Components can subscribe to only the data they need, from wherever they are being mounted. The shared state previously stored in <App /> in our example is moved to the Redux store. When <LikeButton /> mounts, it simply subscribes to the data that it needs from the Store - the programmer doesn’t have to type out a bunch of props being passed in from it’s parent. And if <LikeButton /> needs to change shared application state, it can import actions or action creators directly and dispatch them. Instead of a method on <App />, onLike becomes an action creator.

Conclusion

Redux helps us do less typing, write less complicated code, and develop Components that are free of coupling and easy to reuse.