Looking for advice on separating interface and implementation

[beetee17]

Hi all, I'm currently working on a medium-sized project (~80k loc) that follows the modularisation approach of the isowords app. The project has grown to a few dozen modules, 1 for each feature or dependency. Slowly but surely, build times as well as the speed/reliability of SwiftUI Previews have degraded such that my ability to iterate quickly on features has decreased, and I have since been looking for ways to improve this and maximise my developer experience when working on the codebase.

The Problem

After some research, I believe that the problem with my set-up is that the dependency graph of my modules resemble a hierachical structure (with larger modules depending on smaller ones), and I would like to flatten the graph to become more horizontal. I believe the concepts behind what I'm trying to accomplish are well explained in this video (from 11:36).

Example: Initial Attempt

Disclaimer: I have never done something like this before, so please excuse my ignorance if the idea is completely off-the-mark! I would really love to learn from anyone who knows the solution.

The idea I have been toying with is to create protocols for each feature's Reducer, and rely on the Dependencies library for dependency injection of concrete Reducer implementations. Therefore, a module will be split into two, like so:

App
|-- ChildFeatureAPI
|-- ChildFeatureImpl

// ChildFeatureAPI.swift

@ObservableState
public struct ChildFeatureState {
    public var count: Int
}

@CasePathable
public enum ChildFeatureAction {
    case setCount(newValue: Int)
}

public protocol ChildFeatureReducer: Reducer where State == ChildFeatureState, Action == ChildFeatureAction { }

@Reducer
public struct ChildFeatureReducerMock: ChildFeatureReducer {
    public typealias State = ChildFeatureState
    public typealias Action = ChildFeatureAction
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
    }
}

public struct ChildFeatureClient {
    public var store: (ChildFeatureState) -> Store<ChildFeatureState, ChildFeatureAction>
    public var reducer: () -> any ChildFeatureReducer
}

extension DependencyValues {
    public var child: ChildFeatureClient {
        get { self[ChildFeatureClient.self] }
        set { self[ChildFeatureClient.self] = newValue }
    }
}

extension ChildFeatureClient: TestDependencyKey {
    public static var testValue: ChildFeatureClient {
        ChildFeatureClient(
            store: { Store(initialState: $0, reducer: ChildFeatureReducerMock.init) },
            reducer: { ChildFeatureReducerMock() }
        )
    }
}

// ChildFeatureImpl.swift
import ChildFeatureAPI

@Reducer
public struct FeatureReducerImpl: ChildFeatureReducer {
    public typealias State = ChildFeatureState
    public typealias Action = ChildFeatureAction
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
    }
}

extension ChildFeatureClient: DependencyKey {
    public static var liveValue: ChildFeatureClient {
        ChildFeatureClient(
            store: { Store(initialState: $0, reducer: FeatureReducerImpl.init) },
            reducer: { FeatureReducerImpl() }
        )
    }
}

Example: Adding a parent feature

To make the example more practical, consider a parent feature that depends on the Feature we just created.

App
|-- ParentFeatureAPI
|-- ParentFeatureImpl
|-- ChildFeatureAPI
|-- ChildFeatureImpl

// ParentFeatureAPI.swift
import ChildFeatureAPI

@ObservableState
public struct ParentFeatureState {
    @Presents public var child: ChildFeatureState?
}

@CasePathable
public enum ParentFeatureAction {
    case child(PresentationAction<ChildFeatureAction>)
}

public protocol ParentFeatureReducer: Reducer where State == ParentFeatureState, Action == ParentFeatureAction { }

@Reducer
public struct ParentFeatureReducerMock: ParentFeatureReducer {
    public typealias State = ParentFeatureState
    public typealias Action = ParentFeatureAction
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
    }
}

public struct ParentFeatureClient {
    public var store: (ParentFeatureState) -> Store<ParentFeatureState, ParentFeatureAction>
    public var reducer: () -> any ParentFeatureReducer
}

extension DependencyValues {
    public var parent: ParentFeatureClient {
        get { self[ParentFeatureClient.self] }
        set { self[ParentFeatureClient.self] = newValue }
    }
}

extension ParentFeatureClient: TestDependencyKey {
    public static var testValue: ParentFeatureClient {
        ParentFeatureClient(
            store: { Store(initialState: $0, reducer: ParentFeatureReducerMock.init) },
            reducer: { ParentFeatureReducerMock() }
        )
    }
}

// ParentFeatureImpl.swift
import ParentFeatureAPI
import ChildFeatureAPI

@Reducer
struct ParentFeatureReducerImpl: ParentFeatureReducer {
    typealias State = ParentFeatureState
    typealias Action = ParentFeatureAction
    
    @Dependency(\.child) var child
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
            .ifLet(\.$child, action: \.child, destination: child.reducer())
    }
}

extension ParentFeatureClient: DependencyKey {
    public static var liveValue: ParentFeatureClient {
        ParentFeatureClient(
            store: { Store(initialState: $0, reducer: ParentFeatureReducerImpl.init) },
            reducer: { ParentFeatureReducerImpl() }
        )
    }
}

Notes

Following this article on how to "Separate Interface and Implementation" in the swift-dependencies documentation, TestDependencyKey is used in the interface module, and DependencyKey in the implementation module to provide the live value.

The Issue

The biggest issue of the outlined approach is that State and Action are not interfaces that can be extended (i.e. protocols). This means that a FeatureReducerImpl is unable to layer on additional properties to State, or cases to Action that are only needed privately within that implementation, without also modifying its FeatureAPI module. This constraint feels a bit icky, and makes me wonder if I'm barking up the wrong tree here, though I'm unsure of the alternatives...

At this juncture I'm facing many doubts, not only due to the aforementioned issue, but also questions such as "Is the Dependencies library the right tool for this?". I would really appreciate any feedback on my approach to separating interface and implementation of TCA features, and pointers on how it can be done properly.

[mbrandonw]

Hi @beetee17, unfortunately I believe this approach is probably going to give you more pain than solutions. The dependencies library is not really meant to provide a particular feature's functionality, but rather meant to describe a global service that interacts with the outside world so that any feature can immediately get access. So I don't think it's going to help you much.

The most general technique for flattening a tree of feature dependencies is to simply "delegate up to the parent". So, rather than B navigating to C directly (and hence B depends on C), you have B tell its parent, A, that it wants to navigate somewhere, and then A does the navigation to C. This means B can still navigate to C without actually depending on C, and then only A depends on B and C.

In short, we've turned this dependency tree:

A -> B -> C

…into this one:

A |-> B
  |-> C

So things got a little flatter.

That's the most general technique, and it can work for really any kind of navigation (sheets, popovers, drill downs, etc). But then further SwiftUI provides NavigationStack, which allows you to fully decouple all of the features in a stack.

In that situation you have a path of features:

enum Path {
  case featureA(…)
  case featureB(…)
  case featureC(…)
  …
}

var path: [Path]

…and each of A, B, C, (…) do not depend on each other. Only the parent feature, the one that holds a NavigationStack, needs to depend on all of those features. And whenever A/B/C/… wants to navigate somewhere, they just tell the parent to do the navigation.

[beetee17]

Hi @mbrandonw , first of all, thank you for such a prompt and detailed reply. I really appreciate all the effort you and @stephencelis put into maintaining TCA, and for producing the invaluable content on PointFree. Your work has inspired and motivated me along my iOS development journey!

If I may pick your brain further on your response, perhaps I should have avoided the presentation/navigation use-case in my example. I understand that the delegate pattern can be used to decouple features entirely, like so (I didn't use StackState for brevity):

@Reducer
struct FeatureA: Reducer {
    @ObservableState
    struct State {
        @Presents var b: FeatureB.State?
        @Presents var c: FeatureC.State?
    }
    enum Action {
        case b(PresentationAction<FeatureB.Action>)
        case c(PresentationAction<FeatureC.Action>)
    }
    
    public var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .b(.presented(.delegatePresentC)):
                state.c = .init()
                return .none
            case .b, .c:
                return .none
            }
        }
        .ifLet(\.$b, action: \.b, destination: FeatureB.init)
        .ifLet(\.$c, action: \.c, destination: FeatureC.init)
    }
}

@Reducer
struct FeatureB: Reducer {
    struct State {
//        @Presents var c: FeatureC.State?
    }
    enum Action {
        case delegatePresentC
//        case c(PresentationAction<FeatureC.Action>)
    }
}

@Reducer
struct FeatureC: Reducer { }

Consider another form of parent-child relationship whereby the parent holds a non-optional child state. In this context, is it possible to avoid FeatureB's concrete implementation from depending on FeatureC's concrete implementation? I have included an extremely minimal example below to demonstrate:

@Reducer
struct FeatureA: Reducer {
    @ObservableState
    struct State {
        @Presents var b: FeatureB.State?
    }
    enum Action { 
        case b(PresentationAction<FeatureB.Action>)
    }
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
            .ifLet(\.$b, action: \.b, destination: FeatureB.init)
    }
}

@Reducer
struct FeatureB: Reducer {
    struct State {
        var c: FeatureC.State
    }
    enum Action { 
        case c(FeatureC.Action)
    }
    
    var body: some Reducer<State, Action> {
        // Do not want to use concrete implementation of `FeatureC` here
        Scope(state: \.c, action: \.c, child: ???)
    }
}

@Reducer
struct FeatureC: Reducer { }

Again, the ideal goal is to separate a feature's interface and implementation, such that any feature's (besides the 'Root') implementation module should never depend on another feature's implementation module (only the interface module can be depended upon). Without the @Dependency shenanigans, I came up with this possible approach:

@Reducer
struct FeatureA: Reducer {
    @ObservableState
    struct State {
        @Presents var b: FeatureB.State?
    }
    enum Action { 
        case b(PresentationAction<FeatureB.Action>)
    }
    
    public var body: some Reducer<State, Action> {
        /*Some Reducer...*/
            .ifLet(\.$b, action: \.b) {
                Scope(state: \.c, action: \.c, child: FeatureC.init)
                FeatureB()
            }
    }
}

@Reducer
struct FeatureB: Reducer {
    struct State { 
        var c: FeatureC.State
    }
    enum Action { 
        case c(FeatureC.Action)
    }
    
    var body: some Reducer<State, Action> {
        // Do not want to use concrete implementation of `FeatureC` here, so we do it at the root instead?
        // Scope(state: \.c, action: \.c, child: ???)
        /*Some Reducer...*/
    }
}

@Reducer
struct FeatureC: Reducer { }

However, this appears sub-optimal as it seems that the root FeatureA needs to know about and handle all the dependency relationships of every sub-feature (and sub-...-sub-features) to be able to inject the correct implementations.