How to decouple modules?

[IhorYarovyiCricut]

Hello,

I'm experimenting with TCA in a demo project that features two modules: Notes and Items. In this project, ItemsFeature displays information from NotesFeature (for example, a notes counter), and in a real-world scenario, there could be more complex interactions between these modules.
Currently, ItemsFeature includes the state of NotesFeature directly:

public struct State: Equatable {
    public var items: [Int]
    public var notes: NotesFeature.State

    public init(items: [Int] = [1, 2, 3, 4], notes: NotesFeature.State) {
        self.items = items
        self.notes = notes
    }
}

This creates a direct (vertical) dependency between the features, which, on one hand, enables interaction, but on the other, hinders achieving maximum isolation of the modules. This isolation is important for independently updating different package versions.
I'm considering an approach using a client interface. Instead of directly importing NotesFeature into ItemsFeature, I'd like to create an interface (e.g., a client) that provides data (such as the number of notes) to ItemsFeature. The main app would implement this client interface, allowing the features to remain as decoupled as possible.

I have a few questions regarding this setup:

1. Do you have any established patterns or recommendations for organizing feature interactions in TCA that maintain horizontal isolation while still allowing necessary integration (e.g., for counters, data synchronization, or reacting to events)?
2. Is it advisable to use client interfaces for passing data between modules? Are there any pitfalls or alternative approaches you would recommend to avoid direct dependencies between features?
3. How do you typically handle scenarios where features need to interact beyond simple data sharing, yet you want to preserve their independence (for example, to facilitate easy updates of separate packages)?

I appreciate any insights, recommendations, or examples you could share to help clarify the best practices for organizing such interactions in TCA.

Thank you for your time and for all the great work you do!
DemoApp.zip

[mbrandonw]

Hi @IhorYarovyiCricut, I don't really have anything concrete for you. We don't provide tools specifically for modularity of any kind because this often is very domain specific, and many people like to approach it in many different ways.

The state sharing tools (@Shared and @SharedReader) can certainly be one way of encouraging isolation of features. Multiple features that do not depend on each that can hold onto shared state so that the features are always kept in sync. But this tool is really only intended for holding onto just data, and not meant to be an object that you can interact with and invoke methods on it that implement behavior.

Dependencies can also be another way, as you have noted. But of course, the problem with using dependencies is that it makes testing more complicated, which is one of the biggest reasons to use TCA in the first place. More responsibility will be on you to assert on everything happening in your dependency, and the library will not be able to help you make sure you asserted on everything.