Preamble
ReactJS community now has no one to write class components anymore, family members all use hook because the code is short, beautiful, clear and easy to understand, which is useState, useEffect, useMemo, useCallback, … Not including the very good custom hook . Even Teo – my friend changed from the main fanboy of the class component to the functional component fangirls after using it for a while. However, there is one hook that is easy to confuse for many beginners and also less popular than the other popular but very good guys. It is the useReducer , which is confusing and currently not in use. So my friend Teo didn’t bother to find out why this was born until one day … Teo was caught fixing bugs related to it.
content
1. What is useReducer?
Now, I don’t care about the useReducer hook, so now Teo has to go online to find out, after a while finding out but not understanding, so Teo sighs:
Teo: Hey guys, what this useReducer guy is weird, I always read it but I don’t understand.
Tui: OK, you understand the useState hook, right, I see the ferry code, this is the same as useState so it’s a little more cumbersome to use it, its flow is like redux.
Teo: Whoa!?!?! It’s like a useState guy, but I thought it was related to the redux store, but I saw it had the word “reducer”, thought reducer in the redux store @@
2. Is useReducer related to the Redux store?
Me: Well at first I thought the same as you but it’s not, this one has nothing to do with redux store, it’s just a state management hook like useState but its usage will be like redux flow. There are actions, reducers, types, understand?
Teo: It’s a bit confusing, is there any easier to understand example?
Tui: OK, write the component counter with useState so it’s easy to say
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | function App() { const [count, setCount] = useState(0); const handleClickIncrease = () => { setCount(count + 1); }; const handleClickDecrease = () => { setCount(count - 1); }; return ( <> <div className="App"> <h1>Hello {count}</h1> </div> <div> <button onClick={handleClickIncrease}>+</button> <button onClick={handleClickDecrease}>-</button> </div> </> ); } |
Me: OK, easy too right, now I will rewrite with useReducer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | const countReducer = (state, action) => { switch (action.type) { case "INCREASE": return { ...state, count: state.count + 1 }; case "DECREASE": return { ...state, count: state.count - 1 }; default: throw new Error(); } }; function App() { const [state, dispatch] = useReducer(countReducer, { count: 0 }); const handleClickIncrease = () => { dispatch({ type: "INCREASE" }); }; const handleClickDecrease = () => { dispatch({ type: "DECREASE" }); }; return ( <> <div className="App"> <h1>Hello {state.count}</h1> </div> <div> <button onClick={handleClickIncrease}>+</button> <button onClick={handleClickDecrease}>-</button> </div> </> ); } |
Teo: This is exactly the same as redux, there are actions with reducer and type action, but why do we have to process a little bit but have to be so tired, like holding the Dragon Saber, cutting fruit is too weird
Me: Well, I did say in these cases where to use useReducer, I’m showing you what a useReducer is, how to use it, and especially, it has nothing to do with the redux store =)) But see It is longer than usingState, what else do you see
Teo: uhmmmmm …. Well, the look at actionType INCREASE / DECREASE is to know what it does immediately, logic is collected in one place in reducer so it’s easy to maintain later.
Me: Yeah, right, but are these two different now? And which one should be used over?
Teo: I guess it depends on my taste, whoever likes to use what they use, I still think useState is still delicious, I don’t need to use this hook.
Tui: OK then let’s see more of this example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | function App() { const [data, setData] = useState([]); const [isLoading, setIsLoading] = useState(false); const [isError, setIsError] = useState(false); useEffect(() => { getData(); }, []); const getData = () => { setIsLoading(true); setIsError(false); callingAPI() .then(res => { setIsLoading(false); setData(res); }) .catch(error => { setIsError(error); }); }; return ( <div className="App"> {data.map(item => ( <Item /> ))} {isLoading && <Loading />} {isError && <Error />} </div> ); } |
Tui: Do you think it’s okay now? Currently data, isLoading, isError are being split into 3 separate useStates that are not related to each other and you have to manually handle the update value for each one at a time (start, success, failure), This is currently no problem of logic, but if you look deeper, you will see that these variables affect each other according to the circumstances so in this example try rewriting with useReducer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | const dataFetchReducer = (state, action) => { switch (action.type) { case "FETCH_INIT": return { ...state, isLoading: true, isError: false }; case "FETCH_SUCCESS": return { ...state, isLoading: false, isError: false, data: action.payload }; case "FETCH_FAILURE": return { ...state, isLoading: false, isError: true }; default: throw new Error(); } }; function App() { const [state, dispatch] = useReducer(dataFetchReducer, { data: [], isLoading: false, isError: false }); useEffect(() => { getData(); }, []); const getData = () => { dispatch({ type: "FETCH_INIT" }); callingAPI() .then(res => { dispatch({ type: "FETCH_SUCCESS", payload: res }); }) .catch(error => { dispatch({ type: "FETCH_FAILURE" }); }); }; return ( <div className="App"> {state.data.map(item => ( <Item /> ))} {state.isLoading && <Loading />} {state.isError && <Error />} </div> ); } |
Tui: Seeing now that everything is clearer yet, logic is placed in each code block of the reducer and related states will be linked with the corresponding action, it will be easier to understand. When a project is scaled up then if logic parts using useState are placed in different places it makes things more complicated, and more difficult to maintain, for example it’s debug logic code block code ( reducer) much easier than debug logic in many places. According to boss robinwieruch …
It is not only a state object’s complexity and the number of state transitions that are important, but how properties fit together within the context of an application’s business logic also must be considered when managing state efficiently
3. When to use it?
Teo: Well, it makes sense, later on, if there are also filters, pageIndex, pageSize of all types, then it is true that useState will increasingly swell the source code and cause errors and debug more. But how do I know when to use useState, and when to use useReducer?
Tui: This is not sure, but according to boss robinwieruch’s experience, deciding which one to use at any time depends on each person, it does not completely distinguish between now and then to use this or that time. What is the other that can be flexibly customized to fit your needs, as the boss shared, cases like this should use useState here:
A) JavaScript primitives as state (state is primitives, boolean, number, string, bigInt, Symbol).
B) simple state transitions (simple changeable ones)
C) the business logic within your component (the logic code is in the component)
D) different properties that don’t change in any correlated way and can be managed by multiple useState hooks (different states are not interdependent and can be managed with separate useStates)
E) state co-located to your component (states are attached to the component, this is for example the onChange function of the Input)
F) a small application (but the lines are blurry here)
Me: For cases like these, useReducer should be used:
A) JavaScript objects or arrays as state (state is object or array)
B) complex state transitions (more complex state changes)
C) complicated business logic more suitable for a reducer function (with complex business logic, you should remove the reducer logic in order to focus in one place)
D) different properties tied together that should be managed in a state object (states related / interdependent should be managed by a state object)
E) the need to update state deep down in your component tree
F) a medium-sized application (NB: the lines are blurry here)
G) need for an easier time testing it
H) need for a more predictable and maintainable state architecture (this is too conspicuous)
Summary
Through the above examples, I hope you can distinguish between different useState and useReducer and when to use it to get better source code: v, thank you for reading my article.
Reference sources: