imaccallum/coordinatorkit

coordinatorkit's Issues

How to handle this pattern with a flyout menu in the app

I have different items in Flyout (hamburger) menu in the app. How to make this pattern work in such a case ? Can you share an example ?

Proposal: Router as even more abstract term to get all Tab, Split, Nav cases into the Game

Proposal: TabBarCoordinaators and SplitViewCoordinators itself can also be seen as a Router, maybe we should think of Router as a feature of coordinators.
Actually any kind of Coorindator could act like a Router.
A special Coordinator acting like a Router could select a tab item of its root view controller ('Tab Coordinator' acting as a 'Tab Router') or select a master or detail controller of its root view controller ('Split Coordinator' acting like a 'Split Router').

Some more tidbit of UISplitViewController:
Excerpt of documentation of UISplitViewController:
See https://developer.apple.com/documentation/uikit/uisplitviewcontroller

For example, in a compact environment where the primary view controller is a navigation controller, calling showDetailViewController(_:sender:) does not replace the secondary view controller. Instead, the primary navigation controller pushes the view controller onto its navigation stack.

and:

In a horizontally compact environment, the split view controller acts more like a navigation controller, displaying the primary view controller initially and pushing or popping the secondary view controller as needed.

So as user can switch Apps from Regular to Compact environment (Rotation, Resizing Split Screen of two apps on iPad), the navigation controller in effect may change at any time.
A split view controller modifies the controller stack when switching between compact and regular environments.
That means a child coordinator in tree may use an injected router using a navigation controller that is not the effective one of a split view controller. (Recap: A detail view controller may be added to stack of a master navigation controller)

Maybe we should not store the Router by injection at init of coordinators.
Like any view controller is able to get the nearest ancestor in the view controller hierarchy that is a tab bar controller or navigation controller, we could get the nearest Coorinator acting like a Router of a specific type like 'Navigation Router', ' Tab Router' or 'Split Router' by traversing up the hierarchy of coorinators. Just like traversing a responder chain or getting the NSUndoManager in effect on macOS.

That would allow any coorinator to retrieve the diferent kinds of Routers above and use one or more for push, pop, select etc.
For example, a coordinator down the road could call a showDetail(coordinator:) function of a 'Split Coordinator' above that acts like a 'Split Router' or just a push() of its nearest 'Navigation Router' when not in split view contexts.
Maybe we should add an identifier to Routers to allow Coordnators in sub tree to retrieve a specific Router above (for very complex scenarios like multiple nav/split/tab coorinators in coorinator tree)

Each type of Router may have a specific set of functions defined in a protocol.
'Split Routers', 'Tab Routers' and 'Navigation Routers' do not share much functionality.

What do you think?

presentAuthFlow memory leak

Hey Callum,

when the AuthCoordinator is presented it's also possible to dismiss the coordinator by swiping down, in this case, the coordinator.onCancel() closure doesn't get called and so the coordinator stays in the childCoordinators array. Do you have any solution to solve this issue?

Best Regards,
eduhh94

Memory leak

CoordinatorKit/CoordinatorKit/Router.swift

Line 68 in 7d790f5

completions.forEach { $0.value() }

Will this leak memory? The view controllers in the completions dictionary are not removed after the completion is run.

If so I propose to replace the entire function body with:

        let controllersOnStack = navigationController.viewControllers
        let controller = module.toPresentable()

        navigationController.setViewControllers([controller], animated: animated)
        navigationController.isNavigationBarHidden = hideBar

        if let completion = completion {
            completions[controller] = completion
        }

        controllersOnStack.forEach { runCompletion(for: $0) }

or something similar

Router - setRootModule doesn't clear completions

Hi there, thanks for the implementation.
I think, setRootModule method should clear completions dictionary, otherwise it will keep all added viewControllers into it from deallocating.

Memory leak when setting navigation controller delegate on view controller.

Like with all the other examples and yours, setting the view controller as the delegate to the navigation controller delegate property breaks your closure link responsible for deallocating the child coordinator.

To reproduce, replace this code block into the ProfileCoordinator.swift file and toggle on and off the setting of the navigation controller delegate property in the ProfileCoordinator class to see it in action.

class ProfileViewController: UIViewController, UINavigationControllerDelegate {
    deinit {
        print("deinitialised")
    }
    override func viewDidLoad() {
        super.viewDidLoad()
        self.view.backgroundColor = UIColor.red
        
        //Toggle this line on and off as a comment to see that this view controller is never deinitialised.
        self.navigationController?.delegate = self
    }
}

class ProfileCoordinator: Coordinator<DeepLink> {
	
	let viewController = ProfileViewController()
	private let store: StoreType
	
	init(router: RouterType, store: StoreType) {
		self.store = store
		super.init(router: router)
	}
	
	// We must override toPresentable() so it doesn't
	// default to the router's navigationController
	override func toPresentable() -> UIViewController {
		return viewController
	}
}