We were able to quickly write tests for three different features in the row domain and how they interact with each other. This was only possible due to our desire to run the entire application off of a single source of truth. So, there are a ton of benefits to writing SwiftUI applications in this style, two being that you get instant deep linking capabilities and can write deep, comprehensive tests.

While it is amazing to have test coverage on deep linking and routing in our application, we did have to be on top of our game when it comes to writing the actual assertions. Because we’re dealing with reference types we don’t get the ability to make them equatable and instead need to do remember which fields to assert against, and in fact, our tests as written could be improved a lot.

So, we have now gone really deep into exploring the concepts of navigation when it comes to tabs, alerts, confirmation dialogs, modal sheets and popovers. We are really starting to see what it means to model navigation as state, and how that state starts to take the shape of a tree-like structure, where each next screen is represented by a piece of optional state becoming non-nil, and those optionals can nest deeper and deeper.

Further, we are seeing that in order to properly model navigation state in a tree structure we need to create more and more tools for transforming bindings. This often takes the shape of transforming bindings of optionals, or more generally bindings of enum, and we’ve already discovered multiple of these tools.

But, there is still one extremely important form of navigation that we haven’t yet talked about it, and it is both the most prototypical form of navigation and often thought of as the most complicated: and that’s navigation links. Well, SwiftUI calls them navigation links, but back in the UIKit days you may have known it by “push” and “pop” navigation.

This form of navigation allows you to push a new view onto the screen, with a right-to-left animation, and that new screen will automatically show a back button in the top-left, which allows you to pop the view to the previous one with a left-to-right animation. Further, the view that is presented with navigation links are typically dynamic and have behavior themselves, so just as with modal sheets and popovers we need a way of spawning a new view model to hand to the next screen.

So, it seems like navigation links and modal sheets are quite similar. And honestly we think they are basically two names for the same fundamental thing, but for whatever reason their APIs are very different. Further, we feel like many of the complexities that crop up with navigation links is most often due to incorrectly modeled state, rather than any inherent complexity in navigation links itself. In fact, the tools we built in the previous episodes for transforming and destructuring bindings is going to be extremely useful for navigation links, and will make it far easier to use links than it is with just the tools that Apple gives us.

So, let’s dig in!