Usage of TCA in every view

Hello, I've started to use TCA in the first project since the beginning and noticed one thing.

For my project, I've been creating a DesignKit framework, which is only a reflection of the design system, which was provided by a designer. I've noticed, that in every example inside TCA repo every, even small View wrapped with Store and TCA itself.

From the first place I wanted to avoid any business logic frameworks inside DesignKit, there are only views and nothing more. In my opinion, right now in TCA examples, it looks a little bit over-engineering, but I'm really interested in what other people think about it.

I'm quite new in Combine, but here's my thought how simple views should look like

public struct SomeView: View {
    public enum Action {
        case viewWasSelected

    @State public var viewState: ViewState
    public var output: AnyPublisher<Action, Error>

And after using it inside some big View, which connects to the State will adapt TCA.

Hey Maxim, I agree with you, you definitely do not need to have TCA code infiltrate your DesignKit code. The UI components in DesignKit can be built in a way similar to how SwiftUI's core components are built. They can use @State internally and expose @Binding and action closures externally, and then you hook into that with TCA in your application. We don't have any examples of this in the repo, but maybe we should.

The only time you would want TCA to integrate into a reusable component is if the component has significant business logic and effect execution, and you want to be able to test how that component works in isolation and how it behaves when plugged into features.

We have two examples of this in the repo:

  • Reusable favoriting: This shows how a favoriting button can be designed in TCA so that it can be easily plugged into an existing TCA feature.

  • Reusable download component: This shows how an offline download component can be designed in TCA to be reusable in any TCA feature.

Each of those components have complex business logic and side effects, and so it benefits them to be built in the TCA-style. Any existing TCA feature can simply call .favorite or .downloadable on its reducer, provide the arguments, and it will be instantly enhanced with all of that business logic and effectful work.

However, if you didn't want TCA code to infiltrate these components you could probably rebuild them in a more vanilla SwiftUI style and just expose bindings for the application to plug into.

Does that answer your question?

1 Like

Hi @mbrandonw! Yeah, I'm only was wondering about best practices for creating views components. When I opened a project I've seen that every view is wrapped over TCA and decided to clarify it. Thank you for the quick reply :muscle: