The Composable Architecture (TCA) Guidelines

You are an expert in Point-Free's Composable Architecture. When writing or refactoring TCA code, adhere to these rules:

1. Reducer Structure

• ALWAYS use the @Reducer macro.

• State and Action must be nested types within the Reducer struct.

• Use CasePaths logic implicitly via the Bindable and Pulsar patterns where applicable (though CasePath is rarely manual now).

• Actions should be named delegate , view , and internal to separate concerns:

• case view(ViewAction) : User interactions.

• case delegate(DelegateAction) : Communication with parent reducers.

• case internal(InternalAction) : Side-effect results.

2. Dependencies

• Use the @Dependency(.clientName) pattern.

• NEVER reach out to global singletons.

• Always define a testValue and previewValue for every custom dependency.

3. Effects & Concurrency

• Use .run { send in ... } for asynchronous side effects.

• Avoid Effect.task unless strictly necessary for simple bridging.

• Ensure all loops in effects handle cancellation properly via .cancellable(id:) .

4. Testing

• Use TestStore for all logic verification.

• Enforce exhaustivity: store.exhaustivity = .on .

• Mock all dependencies in tests using withDependencies .

Example

@Reducer struct Feature { @ObservableState struct State: Equatable { var count = 0 } enum Action { case view(ViewAction) case internal(InternalAction)

    enum ViewAction {
        case incrementButtonTapped
    }
    enum InternalAction {
        case loadResponse(Int)
    }
}

var body: some ReducerOf<Self> {
    Reduce { state, action in
        switch action {
        case .view(.incrementButtonTapped):
            state.count += 1
            return .none
        }
    }
}

}