Chapter 13. Redux and React
In the previous chapter, we dived into Flux as an architecture. We saw how problems arise during data sharing across components. We saw different parts of this architecture—Actions, Stores, Views, and Dispatcher—and build upon our example using pure Flux, Dispatcher from Facebook, and EventEmitter. Finally, we built a simple application to see how all these components are tied up together to create a simple flow to share a common state across components.
In this chapter, we will take a look at using Flux in a popular Flux-based state management implementation, Redux. We will see how it differs from pure Flux implementation that we saw previously. We will take a look at different components of Redux—its stores, actions, and reducers for the stores and actions. Finally, we will see how an app connects with the store, maintains a single state of the store, and passes information around in the views.
We will cover the following topics in this chapter:
"Good morning, Shawn," started Mike.
"Good morning, Mike. What are we working on today?"
"Ah, yesterday, we worked with Flux. It was to introduce you to the basics of Flux. In most of our projects, we used something similar to it in order to manage the state in the apps."
"Today, we will see how to use Redux."
"Cool."
"As stated at https://github.coktreactjs/redux, Redux is a predictable state container for JavaScript apps. It's kind of what we implemented previously."
"With Redux, we maintain a single state tree for the complete application and add reducers to enhance the state of the store. Previously, we were directly mutating the value of _state and then notifying the subscribers about the change. Let's take a look at our app setup to get started with, as follows:"
├── actions
│ └── social.js
├── components
│ └── SocialTracker.js
├── config.js
├── containers
│ └── App.js
├── reducers
│ ├── index.js
│ └── social.js
├── server.js
├── store
│ └── configureStore.js...
"Now, there are different things happening here to set up our store. Let's go through them, one wing:."
mapStateToProps: We use this method to define how we are going to map the state from the Redux store to the props being sent to the components connected to listen to the store. Whenever new changes happen in the store, the components get notified and are passed to the object payload from this method.
mapDispatchToProps: This method is used to map the Actions and pass them on the props so that they can be used from within the component.
bindActionCreators: This is used to wrap our Actions creator (SocialActions) into dispatch calls to support calling the actions directly. This helps to call the actions and notify the store for updates, which are done due to the dispatch.
connect: Finally, we have the connect call. This actually connects the React component to the store. It does not change the original component, but enhances and creates a new one. We can then start using...
We took a look at using Redux and setting it up. We saw how it differs from pure Flux implementation that we saw previously. We took a look at different components of Redux—its stores, actions, and reducers for the stores and actions. Finally, we saw how the app connects with the store and we make use of actions and data provided to the component via props.
