Derived Behavior: Optionals and Enums

And just like that we have a pretty comprehensive test that exercises multiple parts of the application and even exercises how multiple domains interact with each other. The fact that we can execute logic in the domain of a single counter amongst an entire list of counters is kind of amazing. Just imagine trying to get this kind of testability and modularity with a vanilla SwiftUI view model. It’s hard to picture, but we will actually be taking a look at that soon enough.

However, before that we want to explore a few more tools for transforming domains. We just saw that the Composable Architecture comes with a tool for transforming a reducer on a local domain into one that works on an entire collection of that domain, along with a tool for transforming a store of a collection of domain into a store that focuses on just one single element of the collection.

That’s cool, but there are a lot of other data structures we may want to pick apart in that way. For example, what about optional state? Or more generally enum state? It’s possible to build tools similar to the .forEach higher-order reducer and ForEachStore view except that they work on optionals and enums instead of collections. To explore these concepts we are going to add a feature to our little toy application.

What if we didn’t want to show a simple alert when we got the fact from the API but instead wanted to show a banner at the bottom of the screen. And to make things a little more complex, the banner will itself have behavior of its own. We’ll add a button in the banner that allows you to fetch another, and it will even manage a little loading indicator that is displayed while the API request is in flight.

Let’s dig in.