With so many of my articles revolving around FRP which are focused around redux being in the app’s foundation, I would love to give any new-comers a great place to start, and for those that are new, Welcome! It is certainly time to see into your programming future, as well as your state’s. In this 3 part guide, we will be covering redux itself, the practices used to write Redux apps using an existing React app, and ways we can make it even better.

With that said, please enjoy.

Ever since the day Dan Abramov presented Redux 1.0 at ReactConf Europe everyone quickly realized the fact that Flux was replaced before their own eyes, and that React had evolved into an amazing framework that wasn’t going anywhere any time soon. Without a doubt redux has made a huge impact on the JavaScript and FRP (Functional Reactive Programming) ecosystems, so it is an understatement to say Redux is nothing short of amazing when working with reactive JS applications.

Like many others I was pretty confused with Redux even after seeing fully functional setups, and even more confusing idiomatic setups. In my mind a lot of this came down to the presentation and the presenter being so far removed from the mindset of a new programmer’s mindset that the disconnect causes many to lose focus with the presentation. Here it is two years later, and Redux almost feels like a rite of passage for JavaScript reactive programming no matter what Frontend framework you use, but was initially created for React.

I always pondered the notion of how to make Redux easy to understand even for those just starting with React, and now is the time to finally make this available. Like everyone says “Redux is simple”, and it certainly is, once you understand the concepts. So without further adieu let’s learn Redux!

It’s All About That State

With React we have two major elements of our application, with one being our state. We use state to keep track of our constantly changing values for our app, like the value of an input box in a form, the total of a counter showing in the view, and anything else that our app depends on to work correctly. This allows us as programmers to see that everything is working correctly, as well as keep from worrying about garbage collection, as well as experiencing the side-effect of inheriting a mindset to keep this state concise, consolidated, and not convoluted.

As your app grows your root component and other class-based components will start to handle more and more state. No matter what the case we always want to make sure that state is handled and updated correctly so our app works as intended. It is when we find ourselves dealing with a spider-web of state being passed back and forth between our components that we quickly see an anti-pattern based on the various ways we try to accomplish this.

Give Props to Props, and State to State

The other element within React Props, is similar to a newcomer when compared to state that its concept tends to throw people off at first. So many find themselves asking “what is the difference between state, and props”. To many and working with other languages these two elements do seem like the same thing, since they sort of act the same at first glance. You can assign data to each, and you can pass both around the application with the stored data, but it is their functionality and limitations that set them apart causing a better application overall.

To quickly summarize, State exists to store the state and constantly changing mutable data of your application, where Props are there as a place to access elements that are usually static, and can help create state. Think of props as the direct line to the static or property data that is not meant to be changed, and state is that data is constantly changed, like if a button has been pressed, or text entered into that input field.

Keep in mind we are not even skimming the surface of discussing external data you may want your application to interact with, but I want to make that clear as it is not very apparent when starting out. We will get there though!

Do You Need Redux?

One rule that has been famous since the release of Redux has been, “if you don’t know if you need redux, chances are you don’t“, or something to that effect. Of course there is a bit of a paradox in this statement, because if you don’t even know how it can help how could you possibly know if you need it? You could write an incredibly intricate React application with the usual uni-directional flow, and may never know if you need redux, all because you were told you didn’t need it if you weren’t sure. I think I would revaluate the marketing team for that slogan.

Still the question stands, especially those new to redux, “Do I need Redux?” Let me start by answering with, “More than likely!“. It does depend on the size of your project, and how much state, and how many actions you handle in that application, either way you will certainly need it in time. Before we get too deep into that we should really discuss what redux is for, and why we want to use it in our projects.

What Redux Offers

Normally I recommend the documentation for projects like this, but it is extremely easy to get lost in the documentation, even as someone using redux; the documentation is so thorough, almost long-winded that it is not something you could read in a day. To spare you all of the gruesome details let us go through a hypothetical situation to explain the need for redux:

Imagine having a React-based project made of several different root components, each with several methods, all using several state entries, and the structure is setup so each component can use the methods from another. To make it even more convoluted they all share a commonality of using a shared API. If you can imagine an app like that, you can also imagine the amount of organization that would be required to make all of this work smoothly without repeating code.

This is not the situation you need to look for to decide if you should use redux, but it does help point out the need for Redux. To quit beating around the bush, Redux allows us to easily organize our methods, including API calls, all of our state, as well as how we want our actions to be interacted with. What we are doing  is removing the constraints of components, and make them controllable across the entire app. There are many more features that make Redux great, but the overall ability is really that simple, but with the way it’s presented elsewhere you probably wouldn’t ever guess.

What Else Redux Does

Saying that organization of code and easy scalability of apps is all that redux does would be fairly ignorant. One of the high points is how Redux continues to hold React within the Functional Programming paradigm, as this functional-based platform shows the benfits of an immutable setup including time travel of state changes. That can be confusing to new-comers, but let’s look at an example:

Your app has a single button that when first pressed shows a message, as well as a button that changes the color of the button. While the button is in its second color, pressing the button again changes the background color. Three seconds after the second click the background-color and button color return to their original colors, and the message goes away.

redux devtools
Redux Devtools

To accomplish this we have to maintain a lot of state to keep track of our events like how many times the button has been pressed, the color of the button, what color the background is, and the amount of time that has passed after the second button press. Without Redux we would change each of these values in our state, but the previous values would be lost as they were changed, but Redux keeps a record of our state change and in turn allows us to reverse the state changes, not only helping us with creating our app, but also debugging our app as well.

 // how we change state with the current state
return {
  ...state, stateChange: change
}

Looking at the above you can see that each time state changes we pass the entire state as the first parameter, and then the change that needs to be made. When we look a bit deeper we notice a new object being created with each change, and that way the previous state is constantly preserved. Developer tools like the Redux Dev-Tools are important to taking advantage of this, giving us access to “Time Traveling” where you can go back and forth through state changes, as well as reset, and commit changes.

This is still only the start of learning and understanding Redux, but we have so many options to make it even better, like implementing Immutable.js into our application with redux.

Why You Shouldn’t Use Redux?

With all of this awesome ability you may be asking yourself, “why would I not want to use redux all the time”? While you could use redux for all of your projects there is a down-side, the increased amount of code as well as complexity that comes with implementing Redux within your app. To give you an idea of what is ahead here is my own redux boilerplate without any app code in it at all, and you should be able to see that there is quite a bit of code just to have Redux in place. To use Redux you need to create an action for each method, a new listener in the reducer, whatever state you need in your store, and then tie all of that into your app. There are always certain situations where this is not entirely true, but we will revisit this when we get to those situations.

Understanding Redux Framework Without Code

Before we jump into the actual code let us step back a moment and take the time to look at Redux in plain english. First I want to point out that redux can be used in various different layouts in apps, and while an idiomatic structure is fairly popular I prefer to present the fully scaffolded layout since it provides more context.

Starting with our folder structure these are the folders we will see, and not just for Redux, but for the entire app.

redux-folder-layout

Actions: Our Redux actions folder

API/Lib: All of our API-based and external library files

Components: Where to add our React components

Containers: Redux containers (routing components)

Reducers: Where the Redux reducers will live

Store: Our initial state and updated Redux functions

Styles: All styling files including CSS/SASS/LESS, and other style-based files

Like any other app our entry point will be our index.js file that lives within the app folder, which in this case is named react-app:

index.js

  • we will provide the Redux store to the rest of the app here, making state excessable
  • being the root of our app we can also include our redux-dev-tools, and routing

store

  • since this is the entry-point for state we need to share such, so we create a store of default keys and value
  • our store will also load our middleware including the dev-tools

actions

  • the actions we want our components to use will be found here
  • if we have APIs to interact with we can import such here

reducers

  • this is our Redux brain which handles the default state, and changes it when needed based on dispatched actions
  • reducers listen for actions which are intercepted within them and change state based on the action received

components

  • these are our views which our users interact with
  • our components import the state, and actions
  • our components can also dispatch actions

containers

  • we can use containers to call multiple sub-components within a component that may or may not need state
  • containers are not a necessary type, but simply something to be aware of.

Of course all of these functions can be placed in other parts of the app, but the main takeaway is how redux is being incorporated, as well as how our app is taking advantage of redux.

The Workflow

With everything in place, we will be dispatching actions from our Components, our action controllers will then call the Action, the associated Reducer will intercept the dispatch, create a new State object, and then the view will Render with the new state. That’s it!

If you are still confused don’t worry, we are getting ready to dive into the meat of it all so that will surely clear things up. In part 2 we will move on to the code and look at how we can put Redux into practice with a React application.

Next: The Beginner’s Guide to Redux: Part 2