Thoughts On You Might Not Need Redux Pt.III

Ben Kudler
Aug 22, 2017 · 1 min read

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.

)
Ben Kudler

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade