In the previous exercise, we wrote reducers that returned a new copy of the state rather than editing it directly. We did this to adhere to the rules of reducers provided by the Redux documentation:
- They should only calculate the new state value based on the
stateandactionarguments. - They are not allowed to modify the existing state. Instead, they must copy the existing state and make changes to the copied values.
- They must not do any asynchronous logic or have other “side effects”.
By asynchronous logic or “side effects”, we mean anything that the function does aside from returning a value, e.g. logging to the console, saving a file, setting a timer, making an HTTP request, generating random numbers.
These rules make Redux code predictable and easy to debug: tests run reliably and other developers know what to expect from your code.
Instructions
We have some reducers here that are breaking the rules!
The reducer in app1.js violates the first rule of reducers: it calculates the new state based on something other than the current state and action arguments.
Fix this by assuming that the song being added will be passed into the reducer as the payload of the action object.
The reducer in app2.js violates the second rule of reducers: it modifies the existing state.
Fix this by using the spread operator ... within a new array instead of using push() on the existing state.
The reducer in app3.js violates the third rule of reducers: it has a side effect. The initial state will not be the same every time you call the reducer.
Fix this by assuming that the random value will be provided as the payload of the action object.
Note that this reducer is called with
undefined. In this case, the default parameter will be used to setstate.