I've had the privilege of using Uber's RIBs framework and corresponding coding pattern from the very beginning as a member of Uber's engineering team in Amsterdam. There was one thing that made it possible to adopt the protocol-based approach and easily write unit tests in a RIBs-based application: a code-generation tool that picked up protocol definitions from the sources of the program and generated mock classes for the protocols. Uber open-sourced RIBs framework in 2017 but did not include the code-generation tools along with it. I saw huge benefits of adopting RIBs architectural patterns in several projects I was involved in, but without a powerful mocking tool, the adoption would be problematic. In this article, I'm introducing the code-generation template that is powerful enough to cover typical use cases found in a complex application that fully adopts RIBs architecture and provides a few useful shortcuts for RxSwift types.
Introducing swift-sourcery-templates (Beta)
swift-sourcery-templates repository contains two code-generation templates (to be used along with Sourcery engine):
-
Mocks.swifttemplate— to generate advanced protocol mock classes that can be used as test doubles in place of object dependencies for unit-testing; -
TypeErase.swifttemplate— to generate advanced type erasures.
Both templates support protocols with associated types and generic functions (with constraints on generic types),
provide reasonable default values for primitive types, and support advanced types and use cases typically found in projects
that use RxSwift, and, in particular, User's RIBs frameworks.
Sample Project
Along with the templates' documentation, I'm planning on publishing the tutorial article. Meanwhile, I'm developing an accompanying project, please feel free to check it out and give code-generation templates a try.
Would appreciate any feedback!
Thanks.
Top comments (1)
Thanks! We use RIBs in our iOS projects and it worked fine until we needed a bunch of slightly different modules that share a lot of common business logic and differ mostly in model types. Making lots generic base classes to extend feels not right in POP/Swift paradigm adopted by RIBs. Will look at type erasure.