I have programmed almost completely in redux/react for 4 weeks now. It seems pretty awesome and I am bullish on it. It is the first time I have ever used a frontend framework on a project and considered replacing standard rails views with. Initially,I had a rough time with it due to the amount of hype around it. So i’m going to explain it the way I wish someone had explained it to me when i first started.

Redux is a Javascript Object that acts as Key/Value store (AKA store) with Strict, Immutable Publish Subscribe Updates (AKA actions)

Store – The main feature of redux is to store the state of your local web application in a single nested key/value store. So if you had a site where people login to store movies they have watched your store would probably look something like your backend database.

[javascript]
store: {
session: {}
user: {}
movies: {}
}
[/javascript]
After you login and visit a couple movies it could be something like

[javascript]
store: {
session: { apiKey: ‘1234’, expiresAt: ‘33999299’ }
user: { firstName: ‘Austin’, lastName: ‘Story’ }
movies: {
{ title: ‘The Matrix’ },
{ title: ‘Dale and Tucker vs Evil’ }
}
}
[/javascript]

Say WHAAAT! Yep. That is all the store is. It is a bunch of key value pairs. The keys are strings and the value are whatever you want. Normally the values are objects, hashes or arrays of objects but they could be numbers or strings.

Now here is where things start to get interesting. You tack on publish/subscribe as the SOLE way to update the store. In publish subscribe you have 2 concepts.

1. You publish messages to your application
2. An array of objects subscribe to those messages and do things based on what the messages are

The subscribers in redux are called ‘reducers’ and you get one reducer per key in your store. So in the above example we would have 3 reducers. sessionReducer, userReducer and MoviesReducer. Those reducers are the sole way to update the value of the key.

So, the sessionReducer is the only thing that can impact the session store which is
`session: { apiKey: ‘1234’, expiresAt: ‘33999299’ }`.

It makes it pretty simple to understand what is affecting the data on your frontend.

Now the publishes are performed by the store using a function on it called `dispatch`.

So a login action would look something like this.

1. Create a userReducer and a sessionReducer, configure redux to have a user and session key in the store.

2. When someone successfully authenticates to your app call `store.dispatch({ type: ‘USER_SUCCESSFULLY_LOGGED_IN, payload: apiData })`

3. In your userReducer and sessionReducer, listen for the message USER_SUCCESSFULLY_LOGGED_IN and when you get it, update the state with the data you care about in the apiData. In your movieReducer, you would ignore the user login message and just return your current state.

4. In the reducers, you never modify the state. Another way to say that, is the value that the key maps to is not changed, instead you either return a new value if you need to change it or you return the old one if the message that was passed in is not something you care about.

This strict updating to a new state provides us with a huge benefit when coupled with React. In react, you map your redux state to react components using react-redux package. So lets say in a profile screen you map to the user store and on a movie screen you map to the movies store. If the user adds another movie, only the movie store state will change, so the user component will not have to change.

I have really enjoyed my journey so far into redux. I am quite bullish on it and hope to keep posting as i learn new things that might help someone along the way.