OK, things are looking pretty good. We’ve cooked up new reducer operators that can hide away details, such as having an explicit dismiss action that can be sent when wanting to get rid of an alert, as well as automatically clearing out state when an alert is interacted with. It requires a little bit of upfront work to make use of this API, but the benefits really start to roll in once we consider testing. The Composable Architecture keeps us in check every step of the way to make sure that we are asserting on how your feature evolves.

But, there are still some things to not really like about what we are doing. The main thing is that when we went to expand this API to also include confirmation dialogs, which for all intents and purposes are basically equivalent to alerts, we just copy and pasted everything and renamed it. That’s a pretty big bummer, and there should of course be a way to unify those two things.

Also, we are currently modeling the alert and confirmation dialog as two separate pieces of optional state, which as we’ve seen time and time again on Point-Free, is not ideal. This allows for non-sensical combinations of state, such as both being non-nil. Ideally we should be able to model destinations as a single enum so that we have compile-time proof that only one destination can be active at a time.

But we aren’t going to address any of that just yet. If we do just a little bit more exploring we can come up with another form of navigation, and seeing these shapes for a third time will help us solidify an API that goes well beyond just alerts and dialogs.

And that next form of navigation is sheets.

Sheets are a great example of state-driven navigation in SwiftUI. They can be powered by some boolean state to control showing or hiding a view, but even more powerful is to control presentation with a piece of optional state, so that when the state becomes non-nil the view is presented, and when it turns nil it is dismissed.

We want to bring this power to features built in the Composable Architecture, but instead of mere optional state powering navigation, we want the optionality of an entire feature’s domain to control presentation.

In particular, the feature we want to show in a sheet is the “add item” view. This is the view that allows you to fill out the details for a new item to add to the inventory, and then you can either add it or discard it.

Let’s try implementing this feature with just the tools that the Composable Architecture gives us, see why they are lacking, and then we will fix them.