Added Navigators to handle navigation programatically

[mcousillas6]

Description:

• Added helpers and basic structure to handle navigation programatically, without the need of using segues.

Advantages

• No more storyboard segues 🎉
• One centralized place to initialise your views and viewModels.
• Separation of concerns, the view does not need to know how to init a viewModel, and the viewModel does not need to know about its view.
• Separates the view from the responsability of handling the navigation stack and leaves that to the routes and navigators.
• Reproducible view setups (if you push to the same view from 3 screens, you don't need to repeat the config in the segue).

Imeplementation details

• The main implementation is in the Navigator.swift file, which implements the base behavior for a Navigation.
• Then, The Route protocol defines a basic interface to create a UIViewController, your Routes are the ones in charge of Creating the UIViewController instance and wire it up with it's corresponding viewModel. Check OnboardingRoutes or HomeRoutes for examples.
• Semantically, A Navigator is in charge of one NavigationStack. So for example, you will have an AppNavigator that manages your root navigation stack for your app and then you could have extra navigator for other flows such as a modal flow that is isolated, or one for each tab on a tabViewController.

[germanStabile]

What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

How about overloading with optional params ?

[mcousillas6]

Looks great! What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

To pass parameters, the best approach is to put them as parameters on your Route, if you are using enums like I did you end up with routes like .login(username: String, password: String) then, you can use that to initialize your viewModel & views properly.

[mcousillas6]

Updated with some improvements:

• Added a transitionConfigurator callback for Routes, so you can set transitionDelegates and so on.
• Changed the way currentViewController works, so it keeps in sync with the actual navigation hierarchy.

[glm4]

Looks great! What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

To pass parameters, the best approach is to put them as parameters on your Route, if you are using enums like I did you end up with routes like .login(username: String, password: String) then, you can use that to initialize your viewModel & views properly.

Do you thing that creating two different routes for the same view but responding to different view models would be a better approach?

[mcousillas6]

Looks great! What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

To pass parameters, the best approach is to put them as parameters on your Route, if you are using enums like I did you end up with routes like .login(username: String, password: String) then, you can use that to initialize your viewModel & views properly.

Do you thing that creating two different routes for the same view but responding to different view models would be a better approach?

Why would you have 2 view models for the same view? 🤔 Normally, Views and VMs have a 1 to 1 relation, with the VM defining the business behaviour.

Either way, If you really need different VMs, yes, having two separate routes is better. I would still go for the parameter approach if you only need to inject some property value, for example, if you have a VM that receives an ID to fetch a profile or similar.

[glm4]

Looks great! What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

To pass parameters, the best approach is to put them as parameters on your Route, if you are using enums like I did you end up with routes like .login(username: String, password: String) then, you can use that to initialize your viewModel & views properly.

Do you thing that creating two different routes for the same view but responding to different view models would be a better approach?

Why would you have 2 view models for the same view? 🤔 Normally, Views and VMs have a 1 to 1 relation, with the VM defining the business behaviour.

Either way, If you really need different VMs, yes, having two separate routes is better. I would still go for the parameter approach if you only need to inject some property value, for example, if you have a VM that receives an ID to fetch a profile or similar.

I meant a view that can be presented in different scenarios using different view models and/or parametes. I think in that case two routes is better to avoid conditionals and extra logic in the same Route case.

[mcousillas6]

Looks great! What do you recommend to handle the case when we need to navigate to a certain UIViewController but the view model/params changes?

To pass parameters, the best approach is to put them as parameters on your Route, if you are using enums like I did you end up with routes like .login(username: String, password: String) then, you can use that to initialize your viewModel & views properly.

Do you thing that creating two different routes for the same view but responding to different view models would be a better approach?

Why would you have 2 view models for the same view? 🤔 Normally, Views and VMs have a 1 to 1 relation, with the VM defining the business behaviour. Either way, If you really need different VMs, yes, having two separate routes is better. I would still go for the parameter approach if you only need to inject some property value, for example, if you have a VM that receives an ID to fetch a profile or similar.

I meant a view that can be presented in different scenarios using different view models and/or parametes. I think in that case two routes is better to avoid conditionals and extra logic in the same Route case.

Oh okay! yes, in that case it's way more clear to have two routes.

[CamilaMoscatelli]

Looks great! :clap: