Routing library for SwiftUI Navigation
- Eric Palma
- Jan 8, 2024
- 3 min read
Updated: Mar 26
At last, I have achieved a version of the Router pattern that I am happy with and addresses the problems I intended to solve when I started.
Remove navigation specific APIs from SwiftUI views.
Prevent views from knowing about other views and how to build them.
Shield views from knowing how other views are navigated to.
It is the result of all the exploratory work and iterations I made in previous posts:
Table of Contents
Removing Navigation APIs from SwiftUI Views
Introducing the RoutingView as a wrapper.
Decoupling views from SwiftUI navigation APIs.
Injecting a Router instance into the view hierarchy.
Moving Navigation Logic to the Router
How the Router manages navigation.
Simplifying view navigation with routeTo(_).
Programmatically manipulating the navigation stack.
Achieving Modularity with the Routable Protocol
Defining navigation for modularized codebases.
Eliminating circular dependencies in the library.
Example implementation of the Routable protocol.
Supporting Deeplinks in SwiftUI Routing
Adding support for deeplinks in a manner compatible with the SwiftUI Routing pattern.
Next Steps and Community Contributions
Future plans for the library.
How to contribute or provide feedback.
Removing navigation APIs from SwiftUI views
The first step was figuring out how to remove any SwiftUI navigation code out of my views. To solve this I created a RoutingView that acts as a wrapper for the view hierarchy.
It contains the SwiftUI navigation APIs for supporting stack navigation, sheet presentation, and full screen cover presentation.
Additionally, it is responsible for creating the Router instance that gets injected into the root view and is used to manage navigation within the RoutingView.
This RoutingView is only responsible for containing the SwiftUI navigation APIs and utilizing the Router object to build views.
Moving navigation logic to the Router for separation of concerns
The Router object is responsible for acting as the gateway to navigation for individual views. It contains the @Publshed properties that the RoutingView observes to trigger the appropriate navigation action.
All views have to do is call the routeTo(_) method and the Router will do the rest. It hides how views are created and navigated to (ie: via navigation stack, sheet, full screen cover).
The object also provides other useful methods for manipulating the navigation stack and dismissing screens programmatically. Below is the improved implementation of the Router:
Join my newsletter for iOS insights, tips, updates + 25% off any subscription plan!
Want to read more?
Subscribe to curiousalgorithm.com to keep reading this exclusive post.
