Unexpected behavior when selecting a new recording in 'Standups' example project

[nesium]

Hi there! Thanks for publishing the 'Standups' case study as a whole. I gave it a spin today and noticed two (most likely related) issues.

Describe the bug

1. After saving a new meeting and selecting the meeting twice from the StandupDetailView, the MeetingView will not appear for a second time.
2. After saving two meetings in a row and selecting any of those meetings, the MeetingView will be pushed without an animation. When tapping the back button - instead of the StandupDetailView - the StandupsList will be visible.

To Reproduce
Add this UITest to the StandupsUITests target: https://gist.github.com/nesium/fbe0c7334c7406b565f5ca6cb99aff47

Expected behavior
The navigation stack should behave as expected, pushing and popping one View at a time.

Environment

• swiftui-navigation version: main branch (a7cd427)
• Xcode 14.2
• Swift 5.7.2
• OS: 16.1.1 (device) and 16.2 (simulator)

[mbrandonw]

Hi @nesium, thanks for the detailed report!

This sadly must have to do with SwiftUI's continuing navigation bugs and our attempts to fix them at the library level.

In particular the bug is this one in which .navigationDestination(isPresented:) simply doesn't seem to respect changes made to its binding. We've tried to work around the most egregious parts of the bug, but it looks like there is more work to do.

I found that something as simple as this fixes the first bug:

struct MeetingView: View {
  @Environment(\.dismiss) var dismiss
  // ...

  var body: some View {
    ScrollView {
    // ...
    .onDisappear { self.dismiss() }
  }
}

I guess this helps keep SwiftUI's internal state consistent.

But sadly it does not fix the second bug. I haven't found a workaround for that yet, but will keep playing around with it. If you discover anything please do share!

[mbrandonw]

Actually, the work around I posted above does not work like I thought. 😕 Currently I'm not sure how to work around these SwiftUI bugs. If you tap around enough times it seems that SwiftUI's internal state becomes inconsistent and eventually just pops itself back to the root.

[nesium]

Hi @mbrandonw. Thanks for looking into these issues and for your (pointfree) work in general in that area!

I saw your Gist and the resulting _NavigationDestination and was afraid that it would be a SwiftUI bug.

Unfortunately I'm not yet firm on SwiftUI workarounds so I don't know how to help with this one at the moment.

I also saw your comment on UITests in the StandupsListUITests. Do you think however that it would make sense to have UITests for this library? Of course you'd be more or less testing Apple's code. On the other hand it feels to me like one has to - to a degree - in order to find the winning combination of view modifiers. I'd be open to help with that if this is something you'd be interested in.

[mbrandonw]

Hi @nesium, yeah I think some basic UI tests for this library is definitely a good idea, especially since we workaround so many SwiftUI quirks. We even started doing this in TCA recently.

[mbrandonw]

Hi @nesium, I think I am going to go ahead and close this issue out as there isn't much we can do in the library since it is an Apple/SwiftUI bug.

However, I will say that iOS 16.4 has fixed many of the bugs we have found in navigationDestination(isPresented:), and we have also rebuilt the entire Standups app using NavigationStack(path:) which also works around these problems. Hope that helps!

[nesium]

That make sense. Thanks for the update @mbrandonw!