Basics of Redux in ReactJS

Redux can come as a challenge even to a professional developer. The reason is when you learn JavaScript (or ECMAScript to be precise), there’s this concept of state. State comes into the picture because JavaScript apps are SPAs or Single Page Applications and work without a page reload. The state of an application keeps a track of the status or the event timeline of the application. For example, you may need to have a flag to identify that the user has uploaded something or that the user is logged in or that a login attempt has failed and you want to enable a “Forgot Password” option etc. You need this flag because the page doesn’t reload and you have to keep a track of this information without relying on a page reload.

The state is all good to use as long as you are using it within a component. Where is becomes cumbersome is when you have to share this state with another component which is not directly accessible from the current component. This might be the situation when you have several components in between. For example, in an ecommerce application you will want to enable the checkout option only if the user is logged in. This means the checkout component will need to reach out all the way to the user component to access its state.

Redux comes to the scene. Redux maintains a central store and manages the state of the application at a global level. This enables any component in the application to just reach out to the central store and get information of the application status / state.

To help understand it better, consider a team working at a construction site. There’s a project manager keeping an eye on everything. And then there are workers working on things. And there’s a worker (Worker B) whose work depends on Worker A. But they can’t see each other or hear each other because of the distance. So they also have Worker C located halfway to keep up the communication. Remember, all these workers are out of the line of sight. So all they can do is shout over the status to each other.

Worker A is filling up the water tank. Worker B needs to turn off the water supply when Worker A is done. Worker C is sitting halfway between Worker A and Worker B so that he can listen to both and update the project manager.

Redux uses four steps to achieve the required functionality.

  1. Store: The project manager. Here the status is managed at the global app level.
  2. Dispatcher: Worker A who shouts outs something. (More on this in a little bit).
  3. Reducer: Worker C who listens to the shout-outs of Worker A and updates the project manager.
  4. Subscription: Worker A waiting for the project manager to give him a heads up and go-ahead.

So in Redux you create a store as step 1. You have a Dispatcher that shouts out what it has done when he has done it. The Reducer then updates the state at a global level. And finally your component can use the updated state of the app to do something within the component.

The components receive all this communication and store it into local variables. These local variables are then used to update the components properties or state or whichever way it suits the component.

There are two pieces of jargon that will come your way when you implement this functionality in your component.

mapStateToProps: This little devil connects the state sent by the Redux store to local variables:

const mapStateToProps = (store) => {

    return {
        localvar: store.somevar,
    };
};

Now you have this.localvar available to use anywhere inside your component.

mapDispatchToProps: How about calling dispatches from within your store to notify other components? Use mapDispatchToProps:

function mapDispatchToProps(dispatch) {
    return bindActionCreators({
        somefunction,
    }, dispatch)
}

And now you can call the dispatcher defined somewhere else, as this.somefunction()

Rest of all is boilerplate that’s used to get the above code working and is worth reading about for a more in-depth knowledge.

Leave a Comment