🕳 The code you don’t have to write
updated 10 months ago; latest suggestion 10 months ago
The best code is no code at all. Approach to coordinators - not writing them, yet having their responsibilities taken care of by the powerful Type system of Swift. ✨
Intro: 🌟 The best code
You've probably already read or heard about this newish idea in iOS world called Coordinators. They decouple view controllers by relieving them from choosing, creating, injecting with data, presenting and otherwise manipulating other view controllers. Leaving each view controller isolated and more focused on actually controlling its view.
Best coordinators are those that you don't have to write, but do actually work.
It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported.
Part one: 🌙 The dream
Isolated View Controllers
In order to coordinate view controllers flow from outside, They have to forget all other view controllers in the app. They must not care if Their parents are navigation / paging / tabs / anything controllers. They must not care in what way nor which view controllers They can present, not to mention the properties They have to populate and the order of methods They have to call for the presenting controller to work properly.
Instead, when view controllers have done something that They can't handle without reaching to other controllers, They should just pass the situation to be handled outside (a coordinator?). And when other view controllers are unwinding back to Them, instead of interrogating properties to decide how to update, somthing from the outside (a coordinator?) should call a clear update method on Them.
Part two: 💡 The idea
Not Writing Coordinators
The key to not writting coordinators is view controllers that match perfectly, that means that the output value of one must match (or can be transformed to) the input / update value of the other. This takes care of any need to know other controller properties or methods!
Still, missing a way to connect the view controllers in a flow that could be used to pass on the matching values and a way to describe presentation. Wait a minute... There is a perfect tool for this - Storyboards! Segues can be used to connect view controllers in a data driven flow and precisely describe presentation - be it a show / push / present / anything custom - that's what they're made for!!
Part three: 🙌 The implementation
Of course, with storyboard segues comes a prepareForSegue that entangles view controllers... Luckily, with input and output types clearly declared, a single implementation of logic can be reused in all controllers - passing an input value and an output handler to destination view controller.
An input value is the output value of source view controller. An output handler is just a closure that queries available storyboard segues and performs the one that has a destination view controller that can take the given output value as an input.
If you like, this implementation can be swizzled in, leaving view controllers prepareForSegue free!!
Overview: 🤔 What now?
The app would still have coordinators - Storyboards, but you wouldn't have to write them. Most complicated and dynamic app flows have been coordinated with a breeze using this technique without a single line.
Knowing that every day we write code that's not needed brings interesting questions - how much, where, why? What code do others not write? What code do you not write?
Talk will have small snippets of code that we do write, but don't have to. Though, it will not be complex or difficult to follow. ☘️
Mr. Grey, great comment!
I've updated the proposal making it clear that the swizzle is optional and can be avoided if one is willing to override it in every view controller.. :D
Though, in this talk I do not plan to go into detail about storyboards and how they can be used in a clear manner. Do you think it's worth mentioning storyboard references (making storyboards simple) and loading of view from xib (making storyboards small)?
I'm skeptical of solutions that require swizzling in general and storyboards in particular. So I'm curious to see how this idea pans out.
Mr. Yellow, thank you for your question :)
I've updated the proposal with a bit more detailed explanation of how the outputs are sent as the inputs for destination view controller.
In the talk, I do plan to explain how this part works (as it is really important), but I'd like to keep things simple.
This is an interesting proposal where it's not clear to me how you mean to avoid Coordinators. If Controller is isolated and Coordinator does not exist – then who will provide input and deliver the output?
Should be interesting to hear this.
Really interesting proposal. The idea of declaratively defining screen inputs and outputs can be used not only to improve code quality, but to encourage deliberate design of data and user flow through an app. Would be great to hear more about how this approach works in practice!