Consider erasing the types in the API

[jihongboo]

Hello. I'm having a problem using your framework.
My project consists of many small swift packages. I define a Router package, and define a route enum in it. But I did not implement the NavigationDestination protocol in this package, because the Router package is a very underlying library and it has no idea about the specific page. I implemented NavigationDestination in the main project and implemented the specific page corresponding to the route.
However, when I try to use the navigate API in the mid-level packages, it is discovered that navigate must accept a routing parameter that implements the NavigationDestination protocol. I think this requirement is not conducive to componentization. Although forced types can avoid unnecessary errors, it binds the definition and implementation together. It is recommended to refer to the system's API NavigationLink, which has no mandatory requirements for the parameter types of routes, and your Navigator itself also supports this API.

[hmlongco]

As has been pointed out, the NavigationDestination protocol specifies the mechanism by which destination enumerations provides views for pushed and presented values. It also provides the for determining the method used by navigate(to:).

This opinionated mechanism is one of the core foundations on which Navigator is based, and won't change.

That said, I can update the signature for func push<D: Hashable>(_ destination: D) to be more inclusive, but since navigate(to:) allows for sheet and cover presentations and since those require NavigationDestination types in order to obtain the presented views, that's all I can do.

"which has no mandatory requirements for the parameter types of routes"

That's incorrect. NavigationLink(value:label:) requires that value be Hashable. The .sheet and .cover presentation bindings require conformance to Identifiable.

Might mention that navigation send also simply uses Hashable values.

[jihongboo]

1. I think it would be more appropriate to restrict the type to Hashable, or provide additional APIs, and only restrict the type to Hashable.
2. navigate carries more functionality, it may not be suitable to use Hashable, but for present and push, its behaviour is more explicit, so it can use Hashable.
3. Considering the modularity issue, the definition and implementation of route are necessarily separated. Need to think about how to handle this scenario.
4. My current interim solution is to add a couple of APIs to Navigator using extension, restricting the type to Hashable.

Translated with DeepL.com (free version)

public extension Navigator {
    @MainActor
    func present(sheet: any Hashable) {
        if let sheet = sheet as? (any NavigationDestination) {
            navigate(to: sheet, method: .sheet)
        } else {
            fatalError("The sheet item must conform to NavigationDestination!")
        }
    }
    
    @MainActor
    func present(cover: any Hashable) {
        if let cover = cover as? (any NavigationDestination) {
            navigate(to: cover, method: .cover)
        } else {
            fatalError("The cover item must conform to NavigationDestination!")
        }
    }
    
    @MainActor
    func push(_ destination: any Hashable) {
        if let destination = destination as? (any NavigationDestination) {
            push(destination)
        } else {
            fatalError("The cover item must conform to NavigationDestination!")
        }
    }
}

[hmlongco]

First, sheet and cover requires values to be Identifiable, not just Hashable.

Second, presenting a sheet or cover requires a source for the view and that's where the NavigationDestination protocol comes into play.

Third, it makes no sense whatsoever for the function signature to say that Hashables are allowed... and then crash when given one just because it doesn't also implement NavigationDestination.

That's trading off compile-time type checking for runtime type checking. And I'm sorry, but that's just dumb. If your requirement is that you need a NavigationDestination, then define it as such in the function signature.

[Raidansz]

From what I can see, and in my opinion, Navigator might not be the best fit for your needs. Relying solely on generics to dictate routing somewhat undermines the library’s purpose. It takes an explicit, opinionated approach to ensure all input states are clear and their navigation destinations are predictable. However, if you’re fond of Navigator, one option could be to use it where it works well for you and fall back on vanilla SwiftUI navigation solutions where it doesn’t meet your requirements.