Revisiting the “Back-Burner” Fundamentals in Programming

A Newcomer’s Attempt to Explain the Confusing Concept of Immutable State to Fellow Newcomers

A lot of information can get thrown at you during the course of an intensive six-month coding bootcamp. Much of that information can be classified as what I like to call “back-burner knowledge,” or the fundamental concepts or ideas that are presented — often hastily or haphazardly — that also require significant research to fully understand. And because there are only so many hours in a week, these concepts are accepted as gospel and then quickly thrown on the proverbial “back-burner” to be studied at a later, or much later date.

Now, as I wrap up my coursework and come to grips with the slightly terrifying prospect of an onerous job search, I’m beginning to revisit these core fundamentals in an effort to look like less of an idiot in any potential interviews that come my way (knock on wood).

Our final phase of coursework covered both React and Redux, two incredibly popular Javascript libraries for building smart, fast, and reliable web applications.

I’ve already touched on the concept of state in another blog post on vanilla Javascript. I actually laugh when looking back at its simplicity now, but suffice to say that React and Redux take state management to a whole new level, especially when it comes to Redux and its store, containing the entire state tree of your application, should you choose to use it.

I should note here that Redux is not always necessary, especially for smaller web applications. Refer to this short article for more on that subject.

When I first learned about the Redux store, I was told that it was absolutely imperative that any updates to said store (via reducers) needed to be done in an immutable way. Hmm…I wonder why, I thought, as I quickly googled immutable vs. mutable state. The results of said search had me throwing the entire idea on the back-burner faster than a procrastination-prone chef.

There was simply too much to understand and not enough time to dive into the benefits of immutability without compromising the rest of my studies. Until now…

My confusion with immutable state in React/Redux had to do with a simple question: “Why do we actually care whether we’re mutating the Redux state in our application?”

After all, isn’t that what we want to do? We want to change the value of our Redux store in some way via our reducers. Why make copies of the original state when we can just cut out the middleman? Wouldn’t mutating the original state increase the performance of our app?

As it turns out, the exact opposite is true. And to understand this, you have to understand the difference between what most programmers call shallow vs. deep equality checks.

Because this is a blog post for beginners such as myself, I’ll just say that shallow equability checks (the kind that Redux uses to compare original state objects to the new objects returned by your reducers) are much more memory efficient. The image below, taken directly from Redux’s official documentation, does a better job than I could ever do at explaining this difference.

In addition, each newly returned object from your reducer returns a unique “slice” of state, that determines whether your components need to re-render or not based on that shallow equality check.

Returning new slices of state also has the added benefit of being safer, because you’re not completely overwriting data that could be critically important in other areas of your application. This practice will also protect against bugs and create a “timeline” of changes so that you can comb through a history of tracked changes to the Redux store’s state. Talk about a win-win-win!

I highly recommend that you take a look at the full documentation page on the benefits of immutability in Redux by visiting this link.

My final project at Flatiron School, a fictional travel agency for traversing the solar system, used a reducer that returned new objects through the use of JavaScript’s spread operator, one of several ways to return new objects without mutating the original state.

Here is a screenshot of said reducer:

There are quite a few other ways to return an entirely new state object from the Redux store, including the slightly older and somewhat less popular Object.assign() method, and by using the .filter method for returning new, filtered arrays. It all depends on what exactly you’re trying to accomplish.

As I look back on the half-year journey I’ve just completed at Flatiron School, I’ve come to realize that there will always be ideas or concepts that an amateur programmer will come across that will require plenty of homework to fully understand.

Truth be told, I still don’t fully grasp the concepts I have touched on in this article, and it’s fine if you don’t either! What’s crucially important is that you continue to delve deeper into those areas of education that are put on the “back-burner” when learning, to be revisited — however many times it takes — to understand the more complicated fundamentals of programming.