Last month, I attended React Boston 2017, the first-ever React conference in the Boston area. Saturday and Sunday were filled with informative and eye-opening talks about the JavaScript library React — especially its newest iteration, React 16, which offers a lot of cool changes — and Redux. I spent my weekend learning about different opinions on creating styled React components, accessibility in React, type safety in React, creating maps and charts in React, server-side rendering in React…You name it. My takeaways from the conference made me even more excited to get back to work, where I’m building features in React, Redux, and TypeScript.
I also spent some time reflecting on my personal React-Redux journey. Up until I took my current role as a software developer at Go Ahead Tours/Education First, I learned — and taught — React as a full-stack developer and instructor at Launch Academy. I grew comfortable with visualizing a webpage as a series of UI components with parent-child relationships, understanding what the “state” of an application referred to and how it could be changed, and creating new objects to represent state rather than mutating the original.
But, when it came to Redux, it felt like I was beyond the Wall, surrounded by white walkers, daunted by the blankness of winter. (A bit dramatic? Maybe).
While I understood the basic flow on a high-level — dispatch an action, use a reducer to inform the store how to update the state, call upon the store as the single source of truth for the application’s state — Redux’s pattern still seemed like something totally foreign and different from the way I was used to doing things in “plain old” React. I also didn’t really get the why of Redux: the piece that usually makes concepts and patterns clearer for me.
It wasn’t until I read about the following concept multiple times and took a few Pluralsight tutorials that Redux, and why we use it, started making sense to me. And, one night while I was out at a friend’s birthday party, the following really clicked:
Redux deals with slices of state. So if the application were a chocolate birthday cake, each individual slice — see where I’m going here? — would represent one part of the state of the entire application. The functions responsible for updating those slices of state are called reducers, and they’re often all tied together via a top-level combineReducers function.
Around the time the conference wrapped up, I came down with a painful ear infection, a nasty cold, and a giant zit. Can you imagine? All at once. (Bad things come in threes). I kept thinking about all the various parts of the human body and how, in a sense, it felt like I had reducers governing each one. (I know, I’m a nerd). I imagined something like this:
One thing I haven’t mentioned — which was also key to my understanding — is that Redux doesn’t manipulate the state of the application directly. Instead, reducers replace those slices of state with new, updated versions of themselves.
Lin Clark has an amazing “cartoon intro to Redux,” which you can find here. She seems to be a fan of metaphors, too. Here’s her take on reducers: “I think of the reducers as a department of white-collar workers who are a little overzealous about photocopying. They don’t want to mess anything up, so they don’t change the state that has been passed in to them. Instead, they make a copy and make all their changes on the copy.”
Reducers comprise just one part of Redux, but understanding them made everything else fall into place for me.
lilydbarrett.com 