Correct structure for PageCoordinator in TabBarCoordinator about xcoordinator

[Narek1994]

I was able to integrate page controller in another controller, but after that it started to not to change while swiping, also manually triggering set for another router doesn't change it

[Narek1994]

Got it, you can close this issue

[pauljohanneskraft]

Great to hear that 🎉

In general, use a new coordinator, whenever you have a new rootViewController that you want to perform transitions on - although it is possible to perform transitions on viewControllers different from the rootViewController of a coordinator, it is not recommended to use this feature, if you can avoid it, since if you have to perform more than 1-2 transitions on a specific viewController, it should probably have its own coordinator.

As a rule of thumb, you can use a new coordinator, whenever you have a new UINavigationController, UITabBarController, UIPageViewController, UISplitViewController - it might also make sense, when you have a viewController that embeds a few other viewControllers.

[Narek1994]

Thanks for reply

If I got you correct, generally until we will face mentioned type of controllers, we should use one coordinator, and if any controller presents more than 2 controllers, it also should have own coodinator. I am correct?

And also if I have one coordinator, for example for login/registration flow, should i describe all route cases in one Route enum, I mean generally for one coordinator we should use one router?

Thanks.

[pauljohanneskraft]

It is more dependent on the actual application actually, as you might want to keep coupling low between unrelated scenes, as such it might make sense for a TabBarCoordinator to have a separate child coordinator as those scenes might be completely unrelated. But it might also make sense to have one big route, if all tabs are actually closely connected. Play a little around with XCoordinator and you will probably get a feeling for it quite fast.

Just think, which scenes should definitely be used together or which do not actually relate to each other. Another example would be a login flow, where the user first decides how to log in (e.g. choosing between Google, Facebook, etc logins), then the user enters username and a password and there might also be some alerts involved. After a successful login, you might want to change to a different coordinator, as the login will be completed at that point and you do not need access to the specific routes of that flow afterwards

[Narek1994]

@pauljohanneskraft Hi, in your example you are keeping strong reference to presented Coordinator, is that required, or I can just create and present in prepareTransition? Thanks.

[pauljohanneskraft]

@Narek1994 You can, but you often do not need to. An AnyRouter also keeps a strong reference to the coordinator that it is representing. In the Example app, there is only the need for strong references, when there is no initial view controller holding a reference to the coordinator. We already noticed that inconsistency and are working on reorganizing references (see #71 for more information), however it might take some time until that (including adaptions) will be merged.

[Narek1994]

Ok Thanks for reply, just dont want to create new issues thats why I will ask my questions here.
I faced the issue where screen can be openned from different coordinators, imagine we have UserDetailScreen which can be openned from 1st tab list and also from second tab list, also from UserDetailScreen you can open another screen, so in your example you pass AnyRouter to viewModel, so what is correct way to implement this kind of things, what should I pass as a parameter of viewModel init, it opens from 2 different coordinators and both have different routers, or should I create coordinator for UserDetailScreen as well?
Thanks.

[pauljohanneskraft]

@Narek1994 You can either create different viewModels or make one viewModel class generic, e.g. by creating a protocol all routes your viewController interacts with conform to. That protocol could look like this:

protocol LoginScreenRoute: Route {
    static func loginSuccessful() -> Self
    static func loginUnsuccessful() -> Self
}

Then your viewModel might look like this:

class LoginViewModel<RouteType: LoginScreenRoute> {
    let router: AnyRouter<RouteType>

    func loginSuccessful() {
        router.trigger(.loginSuccessful())
    }
}