Comments (1)
@onmyway133 Here is a question I asked him on a post here
I’m new to VIPER architecture in swift, so forgive if I misunderstand something ok.
In relation to routing/wireframe, On the original VIPER flow, Information went from view/viewController-> Presenter -> wireframe/router. According to the https://www.objc.io/issues/13-architecture/viper/ they have the following quote:“Since the Presenter contains the logic to react to user inputs, it is the Presenter that knows when to navigate to another screen, and which screen to navigate to. Meanwhile, the wireframe knows how to navigate.”
In CleanSwift however, the view/viewController seems to be the one playing this particular role of the presenter. My question is that since the viewController is now involved in the routing, does that make testing more difficult in anyway? In the original VIPER model, the view/viewController can easily be swapped out while other components are tested. But if in CleanSwift the VC is now involved in routing (and not the Presenter), wouldn’t make the view/VC less of a pluggin when it comes to unit testing?
And here was his response.
You’re right that in VIPER the flow of control is View Controller –> Presenter –> Wireframe. However, the Presenter also talks to the Interactor. Even worse, those arrows are actually bi-directional. The interdependency between the components is kinda messy. It is hard to isolate the components for testing.
You can translate the VIPER quote in Clean Swift terms as follows:
“Since the View Controller contains the logic to react to user inputs, it is the View Controller that knows when to navigate to another screen, and which screen to navigate to. Meanwhile, the router knows how to navigate.”
Imagine you have a button that, when tapped, navigate to a different scene. Who really knows this fact? It’s clearly the view controller because it has the IBAction hooked up to handle that.
The when to navigate is tied to the UI. I don’t think it should be separated out to another component. The how to navigate (i.e. present/popover/dismiss and the transitions) can be extracted to the router.
To force-extract the when to navigate logic to a separate component feels like just moving code around to an unnecessary abstraction layer.
As for testing the view controller’s when to navigate logic, you can simply mock out the router. Then make sure when the button is tapped, mockRouter.navigateToAnotherScene() is invoked.
As for reusability, it is overrated. Realistically, it’s extremely rare that you would want to reuse the view controller, interactor, or presenter. If there is code to be reused, you would put them in workers. The interactors and presenters from multiple scenes can then instantiate the workers to do the common tasks.
I believe application architecture is more important for code organization and ease of making changes, rather than for reusability. You reuse a very specialized part of the code. You don’t reuse architectural components.
Hope that answer your questions about the philosophical differences between VIPER and Clean Swift.
So given those slight differences in architecture, does the VIP implementation breaks the beauty of the VIPER model? I'm not sure that it does. But maybe you could point it out for me?
Or maybe you can point me to a swift implementation that allows the use of storyboards, and segues?
from cleanstore.
Related Issues (20)
- CoreData not working? HOT 1
- Question on Usage : Reload TableView
- Expanding example - Delete user?
- How about swift 3 support ? HOT 6
- Testing viewDidLoad without using Storyboards HOT 1
- Container View Controller Data passing HOT 2
- Clean Junk HOT 2
- passing data from interactor to worker
- Some parts like the router class is not swifty HOT 3
- Latest codes is not in consistence with what's in the blog HOT 4
- Storyboard and nib-less?
- Build is failing
- Question: Worker best practise network+core data HOT 2
- Why tested protocols are suffixed by Spy and not Mock ?
- C
- Clean Swift Refactoring
- Clean swift
- make install command is not working on M1...
- Question: Should the data source of the router be an interactor or a presenter? HOT 1
- OC version HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cleanstore.