Over a million developers have joined DZone.

3 Common Redux Bugs (and How to Fix Them)

DZone's Guide to

3 Common Redux Bugs (and How to Fix Them)

In this post, we go over some bumps in the road developers often run into when working with Redux and how to avoid them.

· Web Dev Zone ·
Free Resource

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

Web developers hate bugs because they lead to malfunctioning applications. Bugs make an application to behave in undesirable ways, something which affects the experience of users.

Redux developers hate bugs, too. Because the JavaScript library is mainly used to manage state in applications, any occurrence of bugs often leads to inconsistencies and unnecessary breakages.

Jonathan Werner, who has over 8 years of experience in the web development industry and teaches developers how to avoid bugs, says that “fixing bugs is integral for guaranteeing the proper functioning of applications—and there is no excuse about it!”

Here are 3 common sources of errors in Redux-powered applications, and some ways of fixing them.

1. Using Redux Unnecessarily

The primary idea in Redux is that entire state of a JavaScript application is kept in a single central location. Although it is normally used with React, the library can be integrated with other React-like frameworks such as Angular, vanilla JavaScript, and Inferno.

With Redux, you can empower every component of your app to enjoy direct access to its state. This way, you won't need to use propsto connect to child components or write callback functions to transmit information to parent components.

While Redux is great for managing the application state, especially in complex applications, it’s not suitable for every situation. For example, if you’re new to React, do not jump to Redux straightaway.

Instead, master the intricacies of React, which you can also use for managing state in applications. And, you should start using Redux only when you get a real need for it, or you intend to implement something new.

Otherwise, if you do not approach Redux with caution, you’ll frown at the bugs and indirection the library introduces to your application—something you could have avoided in the first place.

2. Failing to Observe the Single Source of Truth Principle

Bug-free Redux applications require that the whole state is kept in a “single source of truth”; that is, the state is kept in a central location and any reference to it is made using the single source of truth.

Adhering to this principle will allow you to create universal applications easily, conveniently debug or inspect the performance of an app, and develop your applications quickly.

It can be tempting to incorporate different sources of truth for different purposes. For instance, you may decide to have the login button to be the single source of truth for relaying users access requests and other login details.

Going the route of having multiple sources of truth in your application could make you curse Redux, React, and several other things unrelated to your woes.

Therefore, after keeping a state in a Redux store, ensure that access to it is ensured using the single source of truth. Otherwise, you may end up with unproductive data or other types of shared state mutation bugs that Redux was developed to address.

You should choose to Redux or avoid to Redux your state—without any shortcuts. If you fail to observe this principle, you may not reap the merits of using Redux in your applications.

3. Improperly Using Reducer Functions

Reducer functions are the cornerstone for achieving state management in Redux applications. Therefore, if not implemented properly, you may not achieve the desired results.

Typically, reducers (based on the JavaScript array reduce method) take two parameters: the current state of the application and an action, and return the next intended state.

(previousState, action) => newState

To avoid bugs in your Redux apps, reducers must be pure functions—at all times. It’s advisable that you start with a single reducer function and continually segregate it into smaller units as your application grows in size.

Here are some things you should avoid doing inside reducer functions:

  • Carrying outside effects such as API calls and even routing transitions.
  • Including aspects that can mutate their arguments.
  • Calling non-pure functions such as Date.getHours() or Math.round().

Here is an example of a reducer function that uses ES6 default arguments syntax:

functioncreateApp(state = initialState, action){
      return Object.assign({}, state,{
        visibilityFilter: action.filter
      return state

As seen in the above example, the state is not mutated; a copy is created using the Object.assign() method. Note that Object.assign(state, { visibilityFilter: action.filter }) is also incorrect because it will mutate the initial argument.

Furthermore, the first parameter must be an empty object. Also, note that the previous state in the default case is returned (since it’s for an unknown action).

Wrapping Up

Redux is a wonderful JavaScript library that can be of great help in managing the state of your applications. However, if bugs find their way into your applications, you may not fully realize the benefits of this library.

The best technique to avoid bugs and erroneous code in your application is to develop an extensive understanding of the technology you are dealing with.

Happy bug-free coding!

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

javascript ,redux ,web dev ,react.js ,state management

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}