We’re now in the final stretches of defining our application architecture. We’ve solved three of the five problems that pop up in any moderately complex application, including how the entirety of app state should be modeled in a simple value type, how this state should be mutated using simple composable functions called reducers, and how an application can be decomposed into smaller pieces that can live in their own modules and be understood in isolation.

It’s now time to solve one of the biggest problems we face when building applications: side effects. We’ve talked about side effects a bunch on Point-Free. In fact, our very second episode was dedicated to identifying side effects, understanding how they can impact function composition, and recovering composition by pushing them to the boundaries of the function. We’ve also spent several episodes on dependency injection to show that it’s completely possible to control side effects in a lightweight way using what we called the “Environment”, and how this unlocks our ability to easily simulate and test certain states in our applications that would have otherwise been very difficult.

We want to understand how to model side effects in this reducer-based architecture. There are many approaches to this problem, all with their own trade-offs, but as with everything we do on Point-Free, we want our solution to be transformable and composable.

So, we are going to identify a few flavors of side-effects in our application, and then slowly step through how we can isolate and control the effects. Let’s start by recalling what application we are building…