List of Figures

Chapter 1. Introducing Redux

Figure 1.1. Flux specifies that data must flow in a single direction.

Figure 1.2. Redux isn’t part of any existing framework or library, but additional tools called bindings connect Redux with React. Over the course of the book you’ll use the react-redux package for this.

Figure 1.3. A simple mockup of a profile page. This page is backed by two main pieces of data: the total post count and the list of post objects in the user’s activity feed.

Figure 1.4. A look at how data flows through a React/Redux application. We’ve omitted a few common pieces such as middleware and selectors, which we’ll cover in depth in later chapters.

Figure 1.5. An abstract representation of a reducer’s function signature. If this diagram looks simple, that’s because it is! Reducers are meant to be simple functions that compute a result, making them easy to work with and test.

Figure 1.6. Visualizing a reducer hard at work. It accepts as input an action and the current state. The reducer’s only responsibility is to calculate the next state based on these arguments. No mutations, no side-effects, no funny business. Data in, data out.

Figure 1.7. The store now completes the loop by providing the new state to our profile page. Notice that the post count has incremented, and the new post has been added to the activity feed. If your user adds another post, you’d follow the same exact flow. The view dispatches an action, reducers specify how to update state, and the store broadcasts the new state back to the view.

Figure 1.8. This diagram will anchor your understanding of the elements of Redux as you move forward. At this point, we’ve talked about actions, reducers, the store, and views.

Chapter 2. Your first Redux application

Figure 2.1. A mockup of what you’ll build in this chapter.

Figure 2.2. The home page in a browser after bootstrapping a new React application with the create-react-app command

Figure 2.3. The Redux architecture

Figure 2.4. A store requires one or more reducers and may include middleware. The arrow between middleware and reducers indicates the order in which actions will eventually be handled.

Figure 2.5. The connect method bridges the gap between the store and views (components).

Figure 2.6. A visualization of how React and Redux work together

Figure 2.7. The New Task form

Figure 2.8. Shows the console output from logging the props available to the App component

Figure 2.9. Although views can dispatch actions, they often invoke action creators instead—functions that return actions.

Figure 2.10. A look at your reducer in action. It takes two arguments, the current state of the store and the CREATE_TASK action, and returns the next state.

Figure 2.11. The Redux architecture

Figure 2.12. An example status drop-down

Chapter 3. Debugging Redux applications

Figure 3.1. The Redux DevTools can be used to display actions in real time.

Figure 3.2. The DevTools highlight attributes of the Redux store that have changed as a result of the action.

Figure 3.3. Toggling an action recalculates the application state as if the action was never dispatched.

Figure 3.4. Various monitors can be combined with the Redux DevTools to visualize actions and store data.

Figure 3.5. Navigate to the Redux DevTools via the Redux panel in the Chrome developer tools.

Figure 3.6. The skip, Diff filter, and monitor menu options offer unique ways to visualize and debug state effects.

Figure 3.7. The location of the Chart Monitor

Figure 3.8. The Chart Monitor

Chapter 4. Consuming an API

Figure 4.1. A synchronous action being dispatched

Figure 4.2. An example asynchronous action dispatch

Figure 4.3. The chronological flow of fetchTasks as an async action

Figure 4.4. The fetchTasks async action creator with support for loading states

Figure 4.5. The command fetchTasks now handles the three types of actions that describe a request.

Figure 4.6. Rendering an error message

Chapter 5. Middleware

Figure 5.1. Actions move through middleware, then reducers, prior to the final state being calculated.

Figure 5.2. Example console output after adding the logger middleware

Figure 5.3. Another example of console output from the logger middleware

Figure 5.4. Example output for the create_task analytics event

Figure 5.5. Modeling different strategies for routing as part of an async action

Chapter 6. Handling complex side effects

Figure 6.1. Within the Redux architecture, only action creators and middleware should handle side effects.

Figure 6.2. Sagas will respond to actions of a specific type. If another action type or thunk is received, it will pass through the saga middleware unchanged.

Figure 6.3. Sagas return effects, which are instructions for the saga middleware to perform.

Figure 6.4. Tasks display a timer for how long they’ve been in progress.

Figure 6.5. The takeEvery method spawns a new saga process for each action.

Chapter 7. Preparing data for components

Figure 7.1. Where selectors fit into the larger picture

Figure 7.2. Selectors are optional entities that sit between the Redux store and components.

Figure 7.3. A screenshot of Parsnip with the completed search feature

Figure 7.4. Each new character produces a new action logged by the Redux DevTools.

Figure 7.5. The state Diff indicates that Redux state is updating as a result of the action.

Figure 7.6. Selectors calculate data required by the view.

Figure 7.7. Console output for the double function

Chapter 8. Structuring a Redux store

Figure 8.1. Allowing users to pick from a list of all projects

Figure 8.2. An overview of changes required to fetch and render projects

Figure 8.3. An overview of Parsnip’s components and how they connect to Redux

Figure 8.4. Updates to any part of projects’ state will cause App to re-render.

Figure 8.5. The transition from nested to normalized

Chapter 9. Testing Redux applications

Figure 9.1. Example watch mode output from Jest

Figure 9.2. Jest test output with snapshot tests

Figure 9.3. An example snapshot test failure with a file diff of what was received and expected

Chapter 10. Performance

Figure 10.1. The performance timeline feature

Figure 10.2. Example output from why-did-you-update

Figure 10.3. The “Highlight Updates” option provides a color-coded indication of how frequently updates are made.

Figure 10.4. Parsnip’s main React/Redux configuration

Figure 10.5. A single “cycle” after a user updates a task

Figure 10.6. Instead of connecting one top-level component, you’ll connect multiple lower-level components.

Figure 10.7. A look at how batched actions have state changes rolled into a single dispatch

Figure 10.8. The tasks component tree before attempting to connect each Task component

Figure 10.9. The desired Redux/React configuration

Chapter 11. Structuring Redux code

Figure 11.1. With help from React Redux, Redux exposes a few methods for state management.

Figure 11.2. A Rails-style organization pattern

Figure 11.3. The domain-style, or feature-based, pattern

Figure 11.4. A domain-style alternative pattern that excludes containers

Figure 11.5. A project structure using ducks organization

Chapter 12. Redux beyond React

Figure 12.1. IPC communication between Electron processes