Fatal error when using NBNavigationStack with a non empty path in a conditional

[roland-schmitz-ocu]

Navigation Backport is a great library which enables me to use the much better iOS 16 API also on iOS 14.
Thanks a lot for sharing it.

Although, I found one major issue when using a NBNavigationStack with a non empty path in the else part of a conditional.
It results in a fatal error and looks for the user like a crash.

I can reproduce this behaviour with the following piece of code compiled with Xcode 13.4 and iOS 15.5 in the simulator:

import NavigationBackport
import SwiftUI

enum Item {
    case one
    case two
}

struct ContentView: View {
    // App will crash on iOS 15.5 if showGreen is initially true and the path is not empty
    @State var showGreen = true
    @State var path: [Item] = [.one, .two]
    
    var body: some View {
        if showGreen {
            Color.green.onAppear {
                showGreen = false
            }
        } else {
            NBNavigationStack(path: $path) {
                VStack(spacing: 10) {
                    NBNavigationLink(value: Item.one) { Text("one").padding() }
                    NBNavigationLink("two", value: Item.two)
                }
                .nbNavigationDestination(for: Item.self) { item in
                    Text("Detail \(String(describing: item))").navigationTitle(String(describing: item))
                }
                .navigationTitle("Runnning")
            }
        }
    }
}

It produces the following error message:

NavigationBackport/DestinationBuilderHolder.swift:34: Fatal error: No view builder found for key MyApp.Item
2022-09-27 14:49:16.499575+0200 MyApp[36633:10718781] NavigationBackport/DestinationBuilderHolder.swift:34: Fatal error: No view builder found for key MyApp.Item

A workaround is to always start with an empty path state and then assign the correct path in an .onAppear or .task() modifier.
But this is not in all use case easy to accomplish.

[johnpatrickmorgan]

Thanks @roland-schmitz-ocu for raising this issue. The issue seems to be that under certain circumstances, the DestinationBuilderModifier's onAppear closure is called after the router node's body is computed.

I believe this change is the correct fix, though I want to check it doesn't add too much performance overhead before merging it.

[johnpatrickmorgan]

I've merged the change and released as 0.5.0. Thanks @roland-schmitz-ocu for finding this issue!

[roland-schmitz-ocu]

I tried again with the new version and it now works flawless. Thanks @johnpatrickmorgan for fixing the issue!