The Composable Architecture — One of the Best-Suited Architectures for SwiftUI
As I said in the “SwiftUI is not the future anymore but is right now” article, one of the most important factors to help me confidently use SwiftUI on the production stage is that I have found a suitable architecture. That is the Composable Architecture of Point Free team. This article will focus on explaining why, from my point of view, is this one of the architectures best suited to SwiftUI at the moment? And more importantly, why should you follow up on this architecture.
The completely different programming style and model
The difference about programming models
Two models that I am talking about are event-driven (UIKit) and data-driven (SwiftUI). So what are the differences? How do these differences affect the current mindset?
Well, to get a deep understanding of nature, you need to have bits of knowledge of the concept of the update cycle of the iOS system. I will not go into too much detail in this article, (here are the keywords that you can use to learn by yourself: the iOS update cycle, layoutIfNeeded, setNeedsLayout — sounds familiar?), I am going to give you a quick and short comparison instead:
- Event-driven model: A life cycle will be triggered whenever an event occurs
- Data-driven model: A life cycle will be triggered whenever a piece of data changes
The difference in programming styles
I think the community has discussed too much about this part so I won’t go any further: Declarative programming and Imperative programming. In a nutshell, one is what you want (declarative), one is how to do that (imperative).
The need for a different approach
Obviously, for a game where the rules of the game have changed dramatically, players also need to have new approaches. Many developers have started building their own architectures to meet this criterion. However, the novelty in the approach and mindset makes us have a lot of trouble in creating a clear separation between declarative and imperative style and update life-cycle. For example:
Button(action: {
self.myVariable = "Update text"
self.viewModel.connectToServer()
}) {
Text("Duy Bui")
}Look familiar? If yes, any problems with that block of code? Let's think a little bit before continuing reading.
The problem is that: In the closure, we are using imperative style whereas it should be declarative.
The current problems of vanilla SwiftUI
The example above is one of the most prominent problems — probably the hardest I’ve encountered when using SwiftUI without a proper architecture. Besides, also coming from lack of experience, the use of wrapper properties such as State, Binding has also many problems, leading to spaghetti code. Then when working with other modules such as the network or database, side-effects or asynchronous code started to appear, causing the codebase to lose more and more control.
So in short, the current problems are:
- The confusion (or even the mess) in programming style
- Wrapper properties (such as State, Binding, Published, etc) cannot be properly controlled
- Side-effects and asynchronous code is a big deal
- Testable capability
The composable architecture
Believe or not but the composable architecture (TCA) or Swift composable architecture (SCA) has resolved all of the above problems. The idea (the concept behind) is not new. It was inspired by Redux architecture. It is worthwhile to mention here that how the Point Free team created it. Very consistent, disciplined, and full of passion.
The architecture meets 4 criteria: Understandable, scalable, testable, and composable. They achieved this by using a modern coding style: Functional Programming.
The extremely outstanding ideas throughout this architecture that make it easy to compose are:
- Use pure functions as the base unit
- Composition over abstraction
Conclusion
Well, in this article, I have introduced you to the highlights, to answer the question: Why you should choose Composable Architecture. Of course, there are still a lot of issues needed to be solved, I cannot cover them all within only one article, but in short, I believe we found the right direction to go.
The last reason why I love TCA is I have learned a lot from Point Free. Not only technical lessons but also how they work. They code, they think, they make questions, they refactor, they find another solution, they compare the trade-off, step by step. In the next articles, I am going to get to the point — how to use it.
So, what do you think? Let me know in the comments. Also, don’t forget to share this article with your friends, if you’ve found it useful. Looking forward to all opinions.
