Thoughts On You Might Not Need Redux Pt.II
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 first trade off with Redux is listed as
- Describe application state as plain objects and arrays.
The main issuer with describing application state as plain objects and arrays is that you are never mutating state and you are using very simple data types to manage state.
The former is extremely important and is worth parsing out. The React/Redux/Flux pattern involves not mutating arrays or objects. In further posts I’ll expound upon this, but for now, essentially the pattern is not create new arrays and objects and not mutate old ones, even though arrays and objects are quite good at being mutated.
Running back to the server, getting more information, and then mutating state (i.e. arrays and objects) is extremely tempting because of the two aforementioned data structures. However, one can not do this, because the ENTIRE STATE is described in arrays and plain objects, not just part of the state and not just arrays and objects that are awaiting server based mutation. In thinking about having to have arrays and objects ready to go, or new objects and new arrays ready to be made based on old one’s, suddenly things become a tiny bit more constricting, especially when one thinks about the flexibility of ES6 JavaScript classes. The compulsion to jump to Redux automatically is one third closer to subsiding.
