Thoughts on SwiftUI navigation

[darrarski]

I’m using SwiftUI & ComposableArchitecture for a while already. I found it really nice, and I love the testability. However, with every project, there is one common issue that I’m experiencing - how to design & implement navigation properly.

I want to share my experience in this field. Even with a very simple navigation flow, there are things we need to be aware of and issues we need to address. I focused on two of them and described solutions I use in my apps:

• Programmatically dismissed screens do not animate correctly. This is a problem caused by driving NavigationLink‘s isActive binding with optional state and using IfLetStore for a destination. There are couple of ways we can address the problem. Although it’s easy to overcomplicate the implementation when doing so.
• Dismissing screen and canceling its side effects. This issue occurs whenever we have long-running side effects on a screen derived from an optional state. When we dismiss the screen, we need to cancel these effects somehow. It’s not always intuitive and straightforward, but with a bit of work, it can be done nicely in a clean way.

I wanted to describe how I address the above problems here, but I ended in creating quite a long text. Instead, I will link it here (it’s available on GitHub): darrarski/Thoughts-on-SwiftUI-navigation.

I would love to hear what do you think about the ways I deal with navigation issues. Perhaps there are simpler solutions that I just missed. If you ever experienced other problems when implementing navigation with SwiftUI & ComposableArchitecture - please let me know in this discussion. I hope my experiences will be helpful for you, and I’m looking forward to see your comments.

P.S.: There is also a demo project I made to showcase the issues and solutions: darrarski/tca-swiftui-navigation-demo.

[ferologics]

I feel like TCA should offer the solution #3 as part of the standard library -- though it may be premature, as SwiftUI navigation may be subject to change.

The complexity associated with having to manage multiple didAppear and didDisappear for optional state management is probably the biggest problem I've encountered with TCA ergonomics.

[darrarski]

Given the current state of navigation in SwiftUI, I’m pretty sure it’s going to change sooner than later. Navigation between screens is a crucial part of most apps, and SwiftUI navigation components are still rather limited.

You can check out my extension NavigationLink+Store. It makes a copy of last non-nil state, so the actions dispatched when the original state is already nil - like .didDisappear - can still be handled by the reducer.

I’m thinking of adding a safety feature - we can assert that state was not mutated by the reducer, when the original state is nil and action is performed with a last non-nil state. This way we could catch cases when we mutate the state of the view which is already dismissed (which should be considered an unwanted behavior). If the action does not mutate the state, we can assume it’s fine to dispatch it with last non-nil state, while the original state is already nil.