{"id":239814,"date":"2016-03-28T06:29:28","date_gmt":"2016-03-28T13:29:28","guid":{"rendered":"http:\/\/css-tricks.com\/?p=239814"},"modified":"2017-04-24T07:39:18","modified_gmt":"2017-04-24T14:39:18","slug":"learning-react-redux","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/learning-react-redux\/","title":{"rendered":"Leveling Up with React: Redux"},"content":{"rendered":"

This tutorial is the final of a three-part series by Brad Westfall<\/a>. We’ll learn how to manage state across an entire application efficiently and in a way that can scale without dangerous complexity. We’ve come so far in our React journey, it’s worth making it across the finish line here and getting the full bang-for-our-buck out of this development approach.<\/em><\/p>\n

<\/p>\n

\n

Article Series:<\/h4>\n
    \n
  1. React Router<\/a><\/li>\n
  2. Container Components<\/a><\/li>\n
  3. Redux (You are here!)<\/strong><\/li>\n<\/ol>\n<\/div>\n

    Redux is a tool for managing both data-state and UI-state in JavaScript applications. It’s ideal for Single Page Applications (SPAs) where managing state over time can be complex. It’s also framework-agnostic, so while it was written with React in mind, it can even be used with Angular<\/a> or a jQuery application.<\/p>\n

    Plus, it was conceived from an experiment with “time travel” — true fact<\/a>, we’ll get to that later!<\/p>\n

    As seen in our previous tutorial, React “flows” data through components<\/a>. More specifically, this is called “unidirectional data flow” — data flows in one direction from parent to child. With this characteristic, it’s not obvious how two non parent-child components would communicate in React:<\/p>\n

    \"\"<\/figure>\n

    React doesn’t recommend direct component-to-component communication this way. Even if it did have features to support this approach, it’s considered poor practice by many because direct component-to-component communication is error prone and leads to spaghetti code<\/a> — an old term for code that is hard to follow.<\/p>\n

    React does offer a suggestion, but they expect you to implement it on your own. Here’s a section from the React docs<\/a>:<\/p>\n

    For communication between two components that don’t have a parent-child relationship, you can set up your own global event system. … Flux pattern is one of the possible ways to arrange this.<\/p><\/blockquote>\n

    This is where Redux comes in handy. Redux offers a solution of storing all your application state in one place, called a “store”. Components then “dispatch” state changes to the store, not directly to other components. The components that need to be aware of state changes can “subscribe” to the store:<\/p>\n

    \"\"<\/figure>\n

    The store can be thought of as a “middleman” for all state changes in the application. With Redux involved, components don’t communicate directly between each other, but rather all state changes must go through the single source of truth<\/em>, the store.<\/p>\n

    This is much different from other strategies<\/a> where parts of the application communicate directly between each other. Sometimes, those strategies are argued to be error prone and confusing to reason about:<\/p>\n

    \"\"<\/figure>\n

    With Redux, it’s clear that all components get their state from the store. It’s also clear where components should send their state changes — also the store. The component initiating the change is only concerned with dispatching the change to the store and doesn’t have to worry about a list of other components that need the state change. This is how Redux makes data flow<\/em> easier to reason about.<\/p>\n

    The general concept of using store(s) to coordinate application state is a pattern known as the Flux pattern<\/a>. It’s a design pattern that compliments unidirectional data flow architectures like React. Redux resembles Flux, but how close are they?<\/p>\n

    Redux is “Flux-like”<\/h3>\n

    Flux is a pattern, not a tool like Redux, so it’s not something you can download. Redux though, is a tool which was inspired by the Flux pattern, among other things like Elm<\/a>. There are plenty of guides out there that compare Redux to Flux. Most of them will conclude that Redux is Flux<\/em> or is Flux-like<\/em>, depending on how strict one defines the rules of Flux. Ultimately, it doesn’t really matter. Facebook likes and supports Redux so much that they hired it’s primary developer, Dan Abramov<\/a>.<\/p>\n

    This article assumes you’re not familiar with the Flux pattern at all. But if you are, you will notice some small differences, especially considering Redux’s three guiding principals<\/a>:<\/p>\n

    1. Single Source of Truth<\/h4>\n

    Redux uses only one store for all its application state. Since all state resides in one place, Redux calls this the single source of truth<\/em>.<\/p>\n

    The data structure of the store is ultimately up to you, but it’s typically a deeply nested object for a real application.<\/p>\n

    This one-store approach of Redux is one of the primary differences between it and Flux’s multiple store approach.<\/p>\n

    2. State is Read-Only<\/h4>\n

    According to Redux docs, “The only way to mutate the state is to emit an action, an object describing what happened.”<\/em><\/p>\n

    This means the application cannot modify the state directly. Instead, “actions” are dispatched to express an intent to change the state in the store.<\/p>\n

    The store object itself has a very small API with only four methods:<\/p>\n