flinedev / imperio Goto Github PK

This repo looks great. I'm going to try to use it for a new project. It would be great if you had a sample app that pulled together all the code snippets in your read me.

This library already supports Accio but doesn't document it in the list of supported dependency managers.

Also add the rationale, which is that this way no call to an update() method needs to be made so it can be internal (separating concerns).

Issue

When using start(from viewController: UIViewController), in order to present a view controller, one has to e. g. write code like viewController.present(viewControllerToPresent, animated: true) or viewController.navigationController?.push(viewControllerToPresent, animated: true).

While this works seamlessly, the naming of the presenting view controller is a bit misleading.
In larger function bodies, it's not instantly clear what ViewController viewController is.

Suggestion

By renaming start(from viewController: UIViewController), to e. g. start(from presentingViewController: UIViewController), one could easily solve this issue. Describing the semantics more precisely should fit the point of the whole method.

All are private (implementation detail). The setup should be called in init (for views) or in viewDidLoad (for view controllers). The update should be called in the viewModels didSet. The setupViewModelBindings should be called (if even existent) at the beginning of the setup method. Provide a full example.

In the documentation, it reads

Please don't forget the [unowned self] when using @escaping closures to prevent memory leaks.

... referencing the following example:

func imagePickerStartButtonPressed() {
    let imagePickerFlowCtrl = ImagePickerFlowController { [unowned self] pickedImage in
        // do something with the result
    }

    add(subFlowController: imagePickerFlowCtrl)
    imagePickerFlowCtrl.start(from: mainViewController!)
}

Actually, when the flow controller doesn't hold a strong reference to the child flow controller apart from the one which is created by using add(subFlowController: imagePickerFlowCtrl), there should be no issues.

When removeFromSuperFlowController() gets called as it is supposed to, the flow controller will no longer keep a reference to the sub flow controller. As nothing points to the sub flow controller any longer, it can be cleared, despite not using [unowned self].

Therefore, this declaration is not necessary and should not be proposed in the documentation.

Only case for using `[unowned self] would be when the flow controller keeps a strong reference to the sub flow controller in a variable. Yet, to my understanding, this is not the suggested way to use flow controllers, is only required rarely and doesn't fit the example given in the documentation.

Do you support multiple sub flow controllers, for example, maybe useful in the case of a tab bar.

add(subFlowController: FlowController) can be called multiple times, but it releases the previous controller. Therefore, there can only be one sub.

Hello thanks that you make a framework called like my Dorfdisco, but why is there a present-method without setting animation to false?