Bug in iOS 16.1 NavigationLinks

[tkoehlerlg]

Description

When you use an NavigationLink inside another View that was opened with an NavigationLink, the isActive Bool sends false and the View goes back after it's been opened. Here a video of the Bug:
https://user-images.githubusercontent.com/62466714/199023949-bf08e673-6f63-4504-8383-b31926cb269b.mov

What makes the Bug interesting for TCA is that this only happens when i use the TCA Architecture, but not when i use NavigationLinks with destination and label (without isActive) the bug disappears. Here is a example project:
TCA-App.zip

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

Described in description.

Actual behavior

Described in description.

Steps to reproduce

1. download my example project
2. run and see the bug

The Composable Architecture version information

0.44.1

Destination operating system

iOS 16.1

Xcode version information

14.1

Swift Compiler version information

swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51)
Target: arm64-apple-macosx13.0

[stephencelis]

@tkoehlerlg isActive: Binding<Bool> is available for use with vanilla SwiftUI as well, and this does sound like a vanilla SwiftUI bug. When you tried to reproduce outside of TCA, did you pass along a binding from a vanilla ObservableObject to isActive?

[stephencelis]

@tkoehlerlg Actually, this appears to be an issue of observing too much state. Your app is using the deprecated version of WithViewStore that doesn't have an observe parameter at each layer:

WithViewStore(store) { viewStore in

This observes too much state at each layer, which can expose bugs in SwiftUI that become more common in applications that have a lot of state to observe, in this case a vanilla SwiftUI bug with navigation. TCA comes with tools that you can use to work around these bugs, though. In this case you can use the observe parameter to chip away at just the state a local view cares about. For more info, see our article on view store performance:

https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/performance/#View-stores

As a side note, in addition to using the soft-deprecated version of WithViewStore, which shouldn't autocomplete in Xcode, I see you're also using the soft-deprecated AnyReducer type instead of the ReducerProtocol. Any reason your demo is using these older tools? Curious what articles/docs you're using to learn things.

I'm going to convert this to a discussion now, since it's not a bug with the library, but instead a common SwiftUI bug that we have tools to work around.

[tkoehlerlg]

Wow! Thank you so much @stephencelis, that worked! I will use this to optimise my apps from now on. And for the AnyReducer .. ähm .. swift suggested me this and i not really thought about it. But I will look in the new ReducerProtocol documentation, thank you for the link too :).