Introduction
- State-driven navigation broadly falls into 2 main categories: tree-based, where you use optionals and enums to model navigation, and stack-based, where you use flat collections to model navigation. In this section, we will focus on stack-based navigation and their pros and cons.
Tree-based navigation pros
- Tree-based navigation is a very concise way of modeling navigation. You get to statically describe all of the various navigation paths that are valid for your application, and that makes it impossible to restore a navigation that is invalid for your application. For example, if it only makes sense to navigate to an “edit” screen after a “detail” screen, then your detail feature needs only to hold onto a piece of optional edit state:
|
|
-
Tree-based navigation unifies all forms of navigation into a single, concise style of API, including drill-downs, sheets, popovers, covers, alerts, dialogs and a lot more. See API Unification for more information.
-
More pros here
Tree-based navigation cons
-
For example, in a movie application you can navigate to a movie, then a list of actors in the movies, then to a particular actor, and then to the same movie you started at. This creates a recursive dependency between features that can be difficult to model in Swift data types.
-
More cons here
Stack-based navigation pros
- Stack-based navigation can easily handle complex and recursive navigation paths.
- Each feature held in the stack can typically be fully decoupled from all other screens on the stack. This means the features can be put into their own modules with no dependencies on each other, and can be compiled without compiling any other features.
- The
NavigationStack
API in SwiftUI typically has fewer bugs thanNavigationLink(isActive:)
andnavigationDestination(isPresented:)
, which are used in tree-based navigation. There are still a few bugs inNavigationStack
, but on average it is a lot more stable.
Stack-based navigation cons
- Stack-based navigation is not a concise tool. It makes it possible to express navigation paths that are completely non-sensical. For example, even though it only makes sense to navigate to an edit screen from a detail screen, in a stack it would be possible to present the features in the reverse order:
|
|
- And finally, stack-based navigation and NavigationStack only applies to drill-downs and does not address at all other forms of navigation, such as sheets, popovers, alerts, etc. It’s still on you to do the work to decouple those kinds of navigations.
Implementing Tab View in TCA
Preqrequisites
- The Composable Architecture
1.7.2
. - iOS 17.0+
Create a new project
- Open Xcode and create a new project.
- Add The Composable Architecture package to the project. Go to
File > Swift Packages > Add Package Dependency...
and enter the following URL:https://github.com/pointfreeco/swift-composable-architecture
.
Create the First Tab View
- Create a new SwiftUI View file named
FirstTab.swift
and add the following code:
|
|
- Create similar files for the second tab named
SecondTab.swift
andSecondTabReducer.swift
.
Create RootReducer
|
|
Create RootView
|
|
Implementing Tree-based navigation in TCA
- See more at here
Implementing Stack-based navigation in TCA
- See more at here
Conclusion
- In this section, we learned about the two main forms of state-driven navigation, tree-based and stack-based navigation, as well as their tradeoffs. We also learned how to implement both of these styles of navigation in the Composable Architecture.