Let's talk about using multi-store pattern in TCA as a way to improve the performance and maintainability.
Last week I spoke at NSSpainX to talk about how to use Composable Architecture in larger projects, the kind of issues you might run into and how you can work around them. Mentioned articles are: - Exhaustive testing in TCA - TCA Action Boundaries - TCA Action Boundries - Convenience
Now that we added some structure to our TCA actions, let's add automation and convenience API's.
To maintain our codebases for years, we must create boundaries across modules. Here's my approach to doing that with The Composable Architecture.
Subscribe to premium membership plan
Get access to all premium content and enjoy reading without any distraction
Let's explore couple of atypical Sourcery use-cases.
I've been a fan of Point Free Composable architecture for a while now. I've worked on TCA projects for more than a year on projects of all sizes: from smaller projects like my indie Sourcery Pro, through the New York Times project, to a truly large codebase, a completely new
I like using composition and dependency injection, but when you need to inject each entity with multiple dependencies, it can get cumbersome fast. As the project grows and you need to inject more dependencies into your objects, you will end up having to refactor your methods a lot of times,
Even if we are writing pure Swift code in our app, we still deal with Objective-C Frameworks like UIKit. Let's take a look at how we can improve our MVVM architecture by leveraging a little bit of Objective-C runtime and Protocol Oriented Programming. Popular MVVM setup Pretty standard approach for