How far will props go down?

Created By: gihyeon lee Created Time: May 7, 2020 12:06 AM Description: Review of Redux for 6 months - 1 Last Edited Time: Jul 14, 2020 12:40 AM Status: Publishing Tags: Frontend, React, Redux

Thanks for visiting this post. All feedbacks on this post are always welcome. Please send your the feedback by

This post isn’t talking about a basic of Redux. This post introduces why I use Redux and the process of solving inconvenience while using Redux.




Redux is a state management tool. This is because the motivation to use is inconvenient when the driling props.

When you need user infomation in Root component and CompN-M component, if you don’t use Redux, you have to pass user information from Root to CompN-M.

          | Root |
    |                 |
-----------      -----------
| Comp1-1 |      | Comp2-2 |
-----------      -----------
| CompN-M |

However, if you sue Redux, you don’t need that. You just use the state stored in the store by connecting it to CompN-M.

For the above reasons, I came to use Redux and summarized the problems I encountered and how to solve them.

When creating Action and Reducer, It’s annoying to type one more letter.

When I first created actions.js, reducers.js, they were as follows.

But I thought I could reduce the code by implementing the code more abstractly and i modified it using redux-actions as below.

The number of lines of code has been greatly reduced. The example is applied to only one action and reducer, but there may be many actions and reducers in the actual application. If you want to be comfortable, we recommend using redux-actions.

Is there any asynchronous processing library that is more convenient than the Redux Thunk?

I used to the Redux Thunk. I like it. Because I can use clearly Promise in Redux by that. But I needed a library that could easily use debounce, throttle, cancel, so on. So I found Redux Saga.

The features in Redux Saga I mainly use are as follows:

If you want to learn more, take a look at the following link.

I always hate appending __REQUEST, __SUCCESS, … to action type when get data to backend.

Basically The order when communication from frontend to backend as follows:

  1. Start animation about loading.
  2. Send a request to backend.
  3. Receive a response from backend.
  4. Stop animation about loading.
  5. Print message about a result(success, failure)

The Action is divided based on the above order.

If implemented in code, it is as follows.

If the REMOVE_USER action is added, SUCCESS will be diffrenet, and the rest will be the same. In other words, OOO_COMPLETE, OOO_REQUEST and OOO_FAILURE are likely to overlap in almost all logic that communicates with the backend.

So, I make [routine]( It acts as follows.

The code to which routine is applied is as follows.

Compared to the previous code, the amount of code has decreased considerably.


If you are creating a react application, try using Redux.

And I think that it is better to reduce duplicate code because side effects always occur. You might think, “Should I deduplicate this code?” But you reduce a lot of duplicate code, you naturally feel that your coding skill is improving, so I think I should aim to reduce duplicate code.


과연 props는 어디까지 내려가는가

External Posts

DEV, Medium