Thoughts On You Might Not Need Redux Pt.III
I heavily considered calling this “You Might Not Need Redux, Redux”, but was able to resist the pun.
In Dan Abramov’s great little article You Might Not Need Redux, the second trade off with Redux is listed as:
- Describe changes in the system as plain objects.
This may seem very similar to the first, that the state of the application is in arrays and plain objects, but this is the next step in the Flux/Redux pattern. If there are places in the system, such as is the case with a reducer, where data is in flux, hehe, get it?, that change is described as object keys, whose values will change.
The restriction with this is that whole new objects aren’t going to be chopped in. When a component is loaded state can’t come flying in from multiple different data types across different components, and a component can’t feed in data. Rather, a plain object, what Redux calls a reducer, is going to tell a component when and where to look for changes to its’ state, and self-state storage suddenly becomes very difficult and restrictions abound.
