Unboxing Redux
Tags: redux, javascript, react, softwaredevelopment
Published: 2019-05-18 21:52:10

---
title: Unboxing Redux
published: true
tags: redux,javascript,react,software-development
canonical_url: https://medium.com/@codingsam/unboxing-redux-5510bce4178d
---

[![](https://cdn-images-1.medium.com/max/1200/1*4wwbSLGNbh1m6E-z6y9_Wg.png)](https://medium.com/@codingsam/unboxing-redux-5510bce4178d?source=rss-58cf94a36c97------2)

Redux is just flux with only one store

Redux is a Javascript library that helps developers manage the application state, for instance, it can be the logged in user or the followers of a given user in a social network app.

I am working with Redux for a couple of months and it's being awesome! Something just popped into my mind when I started using it. Then, I remembered that I have read about the Flux design pattern a long time ago. Don't worry if you don't know anything about redux or flux, I will try to make it clear. I just realized something about these two things. I told myself: "So, this is just a flux implementation, but you only have one store".

When I said it like that to some people, that were used to work with Redux, their reaction was something like: 
"What? What is flux?". This was kind of weird because, for me, it was clear that redux was related with flux. But then I realized something. It's really easy to talk about Redux without even thinking about flux. Most people describe Redux just as a application state management library for the frontend, which is true. But I think that is not the most complete answer. If you jump into it and just start using it, you are missing the big picture. Don't worry, I am not judging! If you just joined a project that uses this library, you have to learn how it works and get stuff done, right? It can take some time until it all makes sense.

If you don't know what redux is, you came to the right place. I will try to explain it to you in simple words. Even if you are familiar with Redux, are you sure you really know what it is and where all its concepts come from? 

I think that, defining redux implies that you first explain what flux is. Once you understand it, redux just comes out naturally and you will see why I define it as a "flux with only one store".

This is not a flux or redux tutorial. In this post, I will do the "*unboxing*" of Redux, which means, I am going to try to explain what it is and where its core concepts come from.
If you are already lost, don't worry. I will break it down so you end up understanding what Flux and Redux is. Then, you can jump into the [Redux getting started](https://redux.js.org/introduction/getting-started) guide and start building awesome projects!
Let me "*unbox*" Redux for you.

## Flux

When I open the Redux box, the first thing I find is [Flux](https://facebook.github.io/flux/). It is a design pattern, created by Facebook, for managing the application state. I am not going to focus on any particular implementation. I think once you understand the pattern, you can just find any implementation and start using it.
It has *actions*, a single *dispatcher*, one or more *stores* and of course the *views*. Let's break it down:

* *Action*: This is just an object that needs, at least, to have a type key, which will define the action's type. This type will be used later on to make decisions about state updates

* *Dispatcher*: Its responsibility is to send the actions to all the stores

* *Store*: The store receives the actions and updates the application state accordingly

* *View*: This is just the UI component that the user is interacting with

The following diagram shows the main components of this pattern and how they interact with each other:

![Diagram that shows how the Flux pattern works](https://cdn-images-1.medium.com/max/1600/1*xsAiyYD66qYqIxkJrsBl0g.png)

It works like this:

* The user interacts with the app *views* and those interactions will create *actions*

* *Actions* are sent to all stores through the *Dispatcher*

* Each *store*, that is programmed to listen to a given *action* can update its state

* The new state will be available for the *views* to use if they need to

Each store is responsible for handling the state and logic for a given domain. For instance, if you are creating a social network, you might have one store for managing users and another one for the feed. Some stores will listen to the dispatched actions and some stores will just ignore it, it's up to the developer to decide which store cares about which actions. In this example, an action could be "the user's feed is fetched" or "the user requested to follow another user".
This is a really simplified view of Flux. I recommend that you dive into the [oficial documentation](https://facebook.github.io/flux/docs/in-depth-overview.html).

Now that I showed you what was inside the Redux box, the Flux pattern, let's move on to the box itself… Redux!

## Redux

After looking at Flux, change it to only have one store and add the concept of *Reducer*. That's it, now you have Redux.
The following diagram shows how the different components of Redux interact with each other:

![Diagram that shows how Redux works](https://cdn-images-1.medium.com/max/1600/1*j69swQLVOLX7gwj3vUFeVw.png)

It works like this:

* The user interacts with the *views*, which can create some *actions*

* Those *actions* are dispatched (through the *Dispatcher*) to the *reducer*

* The *reducer* receives the current state and the action and it returns the new state

* The views now just have to get the new state from the *store*

Looks pretty much like Flux, right? But you only have one store. The only way to change the state is dispatching an action. The reducer will get it and return the new state. One really important thing about the reducer is that, it must be a *pure function*, which is a function that produces the same result for the same arguments and doesn't have any side effects. This means that the reducer has to create a new state object instead of modifying the existing one. This is the only way for Redux to detect that the state was updated.
For instance, if you are working on a social network project, your state could look like this:

```json
{
  "followers": [],
  "following": [],
  "feed": []
}
```

And the reducer…

```javascript
function reducer (state, action) {
  switch (action.type) {
    case "FETCH_FEED_SUCCESS": {
      const { feed } = action;
      return { ...state, feed };
    }
    case "FETCH_FOLLOWERS_SUCCESS": {
      const { followers } = action;
      return { ...state, followers};
    }
    case "FOLLOW_SOMEONE": {
      const { userToFollow } = action;
      const { following = []: currentFollowing } = state;
      const following = [...currentFollowing, userToFollow];
      return { ...state, following };
    }
    default:
      return state;
  }
}
```

The default case does not need to create a new object because it's not modifying the state.
Having only one reducer will take us to a really big and messy reducer function, right? Well, fortunately you can split the reducer into multiple functions and each one will be responsible for handling only part of the state.

```javascript
// Feed reducer
function feed (state, action) {
  switch (action.type) {
    case "FETCH_FEED_SUCCESS": {
      const { feed } = action;
      return feed;
    }
    default:
      return state;
  }
}

// Followers reducer
function followers (state, action) {
  switch (action.type) {
    case "FETCH_FOLLOWERS_SUCCESS": {
      const { followers } = action;
      return followers;
    }
    default:
      return state;
  }
}

// Following reducer
function following (state, action) {
  switch (action.type) {
    case "FOLLOW_SOMEONE": {
      const { userToFollow } = action;
      return { ...state, userToFollow };
    }
    default:
      return state;
  }
}
```

You can do this thanks to the [combineReducers](https://redux.js.org/api/combinereducers) function. All your combined reducers will receive any action you dispatch. You have to do this because there is only one store here, which means, only one reducer.

Like Flux, you still have actions and the store but, in a more simplified way. You just need to dispatch actions and handle the state changes in the reducer.

You can use Redux with any UI framework of your choice. There are some packages that give you some functions that makes easier to connect your framework to the redux store. For instance, you have [react-redux](https://github.com/reduxjs/react-redux) package if you want to use Redux with [React](https://reactjs.org/).

## Conclusion

It's really easy to jump right into redux without understanding what inspired all those concepts, such as, actions and the store. I think it's important to get the big picture and learn about flux, even if it is just a simplified overview, like the one you just read. Flux can be a bit tricky to get at the first glance. I think Redux gives you this pattern in a much more simpler and easier way. You only have one store and state updates are handled by reducers, that need to be pure functions.

Next time someone asks you what is redux, you can just do this unboxing. You first show the Redux box. Then, you open it and take Flux out of the box. Now you explain Flux and in the end, you get back to the Redux box and everything makes sense. This is why I define Redux with this simple sentence: "_Redux is just flux with only one store_".

I hope you enjoyed and learned something. Happy coding! :)

Let me know what you think and follow me for more cool content about dev stuff :)

[codingsam01 @ Twitter](https://twitter.com/codingsam01)

[codingsam01 @ Instagram](https://www.instagram.com/codingsam01)