Component communication

[Supereg]

Component communication

♻️ Current situation & Problem

Currently, there is no easy way for a Component to access features or information provided by another Component.

I illustrate the usefulness using a real-world example we are currently facing with SpeziAccount. A AccountConfiguration is used by the user to configure the SpeziAccount subsystem which in turn does everything necessary to set up the request AccountServices to be accessible by the App's views. While one may just provide off-the-shelve AccountServices using the initializer of the configuration object, there might be instances where an third-party AccountService is controlled and configured by a Component. In such cases it should be possible for the user to place the Component in the Configuration closure as usual with the AccountConfiguration querying AccountService instances from all configured Components.

let config = Configuration(standard: TestAppStandard()>) {
    AccountConfiguration {
        SimpleAccountService()
    }

    FirebaseComponent() // a component preforming necessary initialization steps for its AccountService
}

💡 Proposed solution

In this PR we introduce the @Provide and @Collect property wrappers that can be used to pass around information or functionality between Components. The @Provide property wrapper is used to supply a single Value (or Value? if it e.g. only supplies it conditionally) or multiple values ([Value]) to be collected by other Components.
Another Component can then use @Collect with a type of [Value] to collect all the provided items.

Here is a short code example:

class FirebaseComponent<ComponentStandard: Standard>: Component {
    @Provide private var accountService: any AccountService

    init() {
        // @Provide have to be initialized before the components configure() method is called
        self.accountService = FirebaseAccountService() // may also be initialize inline
    }

    func configure() {
        // do firebase initializations 
        accountService.configure() // as its a reference type, we can adjust state
    }
}

class AccountConfiguration<ComponentStandard: Standard>: Component {
    @Collect private var accountServices: [any AccountService]

    func configure() {
        // @Collect can be used within the configure method
        // ...
    }
}

While the example shows the usage of a reference type, this feature can also easily be used with value types (though then, no modifications post the collection phase are possible).

⚙️ Release Notes

• Added @Provide and @Collect property wrappers for easy to use inter-Component communication
• Added a generalized and reusable SharedRepository pattern to easily implement typed collections.

➕ Additional Information

Shared Repository Pattern

This PR additionally introduces the concept of the SharedRepository software pattern based on Buschmann et al. (Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing). We provide a variety of different types of KnowledgeSources which are stored in SharedRepository implementations. Each shared repository defines a SharedRepositoryAnchor it expects from an implementing KnowledgeSource.

This instantiation of the shared repository pattern replaces the previous TypedCollection implementation. Further, it will be of equal use for SpeziAccount (storing arbitrary account details). The current draft PR introduces a similar concept. This PR helps to generalize this software pattern and increase code reuse across the framework ecosystem.

Alternative Considered

As with the previous TypeCollection implementation, a SharedRepository allows for a collect(allOf:) query which is, e.g., internally used to query all Components that conform to LifecycleHandler. Instead of the proposed system, we could have created a property wrapper that just collects all components that conform to a given protocol. I decided against this approach considering the following points:

• The alternative solution would not allow to prohibit propagation of information (only by the visibility of a protocol itself).
• The alternative solution would allow to circumvent the current @Dependency system (or we would need to consider '@Collect` declarations in the execution order).
• The alternative system would be limited to just retrieve protocol conformances.
• The proposed solution decouples propagated information from the Component by default allowing for arbitrary information (value types, reference types, information, functionality).

Related PRs

• Rethought Account Service Model with reimagined Account Setup and new Account Overview SpeziAccount#7

Testing

Test cases were adapted but still need to be extended for newly added code.

Reviewer Nudging

There are two separate parts to the PR:

• The SharedRepository data structure
• The Collect and Provide property wrappers. You may look at the tests to easily glance what their use case is.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

Merging #72 (03e84f3) into main (162c932) will decrease coverage by 0.61%.
The diff coverage is 92.24%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
- Coverage   89.45%   88.83%   -0.61%     
==========================================
  Files          30       44      +14     
  Lines         635      743     +108     
==========================================
+ Hits          568      660      +92     
- Misses         67       83      +16     

Files Changed	Coverage Δ
Sources/Spezi/Adapter/Adapter.swift	0.00% <ø> (ø)
Sources/Spezi/Adapter/DataChange.swift	100.00% <ø> (ø)
Sources/Spezi/Adapter/SingleValueAdapter.swift	100.00% <ø> (ø)
Sources/Spezi/Configuration/Component.swift	100.00% <ø> (ø)
Sources/Spezi/Configuration/Configuration.swift	100.00% <ø> (ø)
Sources/Spezi/DataSource/DataSourceRegistry.swift	50.00% <ø> (ø)
...Provider/DataStorageProvidersPropertyWrapper.swift	100.00% <ø> (ø)
...dule/Capabilities/Lifecycle/LifecycleHandler.swift	100.00% <ø> (ø)
...s/ObservableObject/ObservableObjectComponent.swift	86.37% <ø> (ø)
Sources/Spezi/Spezi/SpeziSceneDelegate.swift	83.34% <ø> (ø)
... and 25 more

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 162c932...03e84f3. Read the comment docs.

[PSchmiedmayer]

Thank you so much for all the changes there @Supereg, a huge step forward 🚀

I had a few comments here and there. Overall the PR looks great and feel free to merge it after addressing some of the comments and iterating on some of the features. Thank for all the work and time that goes into this project.

Very cool to see some of the @Apodini aspects making a reappearance here; more and more of the learnings from that project are applied to @StanfordSpezi, very nice!

[Supereg]

@PSchmiedmayer I addresses all the feedback. Wanted to re-request your review just to make sure 🚀

[PSchmiedmayer]

Thank you! I will have some time in the late afternoon to re-review the PR. If it is fine with you I can fix smaller issues that I might find myself and then merge the PR after that? Maybe I don't even have some feedback and could also directly merge it 👍

[PSchmiedmayer]

Amazing job with the PR @Supereg, very nice additions and a superb code quality!