Public init for Navigator

[3a4oT]

• made Navigator's initializer public so it can be instantiated from a different module.

[frzi]

Can you give an example of a scenario where you'd need to initialize a Navigator manually? By design it's only meant to be initialized by the Router. Thanks!

[3a4oT]

Sure, I use it in TCA tests where I have currentRoute on each state. To test that my app navigates to the correct route after some action I need to mock Navigator but because of internal init I can't.

[frzi]

In tests you should be able to use @testable import SwiftUIRouter. This grants you access to all internal properties, methods et al. Including Navigator's init.

I'm hesitant to make Navigator's initializer public as it's considered part of a private API. Its initializer being public would be useless in normal case scenarios and its presence could therefore be confusing to new users. 😄

[ghost]

@frzi We have an Scenario. We could provide the Navigator to our dependency container first and not have to be forced to use the environmentObject. Navigator could live in global scope for global/common dependencies.

But that would require that the Router has an initializer with Navigator.

[frzi]

I've made a separate branch named dev/public-navigator to try this out. This branch provides a public initializer for Navigator, as well as a new init for Router where you can pass a manually initialized Navigator.

The specific branch can be added using the following dependency descriptor in Package.swift:

.package(url: "https://github.com/frzi/SwiftUIRouter", .branch("dev/public-navigator"))

Or modify the package in Xcode under Project > Package dependencies:

Keep in mind I'm still hesitant adding this to main and would advice to avoid this workflow as much as possible. The concept of the Navigator is that it's an integral part of Router and only exposed inside the hierarchy of Router. Exposing it as an Environment Object only largely ensures a Navigator is always tied to a Router.

Otherwise, if this really proves to be a roadblock to working with SwiftUI Router in TCA I will consider pulling this branch into main.

[ghost]

@frzi dev branch works as expected.

Currently we using it like so.

• global SideEffect stream
• ViewTree -> ViewModel (global scope) -> perform user action -> trigger side effect
• Navigator -> environmentObject in View -> listen for Sideeffect -> handle navigation

What now possible is

• global Navigator
• ViewTree -> perform user action -> ViewModel -> handle navigation via Navigator

[frzi]

Closing in favor of #25