Things that were inconvenient while using Redux

This post isn’t talking about a basic of Redux. Before reading this post, it is helpful to read “How far will props go down?”.



The following explains the inconveniences of using Redux.

Non-intuitive Logic

The basic Redux code is shown below.

If anyone who doesn’t know Redux sees the code above, can he/she knows exactly how n increases by 1? Honestly, I didn’t understand at first. I didn’t understand where the arguments (state, dispatch) of mapStateToProps, mapDispatchToProps are input and what is input. I thought I should just use it like that.

I thought I lacked understanding, but when I told my co-workers that this was happening, there were quite a few people like me.

Empty state data, not needed

Suppose you implement a bulletin board with the following requirements.

If you use Redux, you can set InitState as below.

However, posts are useful only on the /posts page, and not required for the /posts/:postID page. Currently, there are only two pages, but if there are many pages like the admin application and there are few states used for one page, the empty status data will increase.

There was a lot of empty state data that I didn’t need, making it inconvenient to debug in NEXT.js + Redux DevTools, and poor readability.


Redux has its advantages, but also its disadvantages. However, the disadvantage of having a large learning curve can be covered by learning, and empty state data that are not needed can be avoided by good state design. And if you use Redux well, you can build your application more easily. For example, the pattern that implements business logic in the container and the part that communicates with the backend is implemented in the slice module, so that other developers can code predictably, thereby ensuring high readability and productivity.


Redux를 사용하면서 아쉬웠던 것들

External Posts