Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where to config? #5

Open
onmyway133 opened this issue Dec 15, 2015 · 3 comments
Open

Where to config? #5

onmyway133 opened this issue Dec 15, 2015 · 3 comments

Comments

@onmyway133
Copy link

In https://github.com/Clean-Swift/CleanStore/blob/master/CleanStore/Scenes/CreateOrder/CreateOrderViewController.swift,

override func awakeFromNib()
  {
    super.awakeFromNib()
    CreateOrderConfigurator.sharedInstance.configure(self)
  }

We lean on the life cycle of the ViewController to config things. How about moving Configuration task to where the module is created?

@ehlersd
Copy link

ehlersd commented Dec 15, 2015

?? Are you suggesting calling the configure in the parent where the module is allocated?

@onmyway133
Copy link
Author

@ehlersd yes, it is. Like Wireframe in VIPER, it initiates and configs the next whole module

@ehlersd
Copy link

ehlersd commented Dec 15, 2015

Hmmm....I haven't dug into VIPER before. Personally, I can see arguments for both ways.

Pro CleanSwift Configurator: Having the config code inside the scene removes any outside responsibility for the scene as a whole, and keeps redundant initialization code inside the scene itself. This makes it easy to copy the scene (as a whole) to another project and "hook it up" thru the storyboard with literally zero code change/additions to the existing app base.

Pro VIPER Wireframe: If you move beyond treating the scene as a whole unit, and instead look at the different pieces as "reusable" and interchangable, then it does make sense to pull the config code out of the scene itself, as the outside source (ie: Wireframe) can pick and choose what Presenter and what Interactor is hooked up to what View (ie: DI). IMHO, there is a lot of value in this approach, IF you are looking for that level of decoupling.

I've approached my scenes slightly different. I've pulled out most of the "reusability" into separate "Workers" (which also are connected using defined protocols), so the reusability of the Interactor and Presenter are limited. The Interactor is much more of JUST business logic, specially designed for this specific view. Also, I tread the scenes as individual "lego" parts that cannot be separated.

But, of course, I see the value in both approaches. I may have to play with VIPER some on a future project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants