Inject Spezi Components as ViewModifier into the SwiftUI view hierarchy

[Supereg]

Use Case

There is a general need for Spezi Components to either inject information or retrieve information from the SwiftUI view hierarchy. We already have the ObservableObjectProvider to inject Observable Objects into the view hierarchy. However, components might want to do more. There is a use case for SpeziAccount, where Account Services might want to inject view components globally (e.g., an alert box to reauthenticate on security related operations) or SpeziFirebase that requires access to the AuthorizationController that is part of the SwiftUI Environment.

Problem

Doing any of this, except for injecting ObservableObjects, is not supported by Spezi and requires custom modifiers or, generally, requires a manual approach.

Solution

A viable solution is to make all Component s conform to the SwiftUI ViewModifier protocol and injecting the into the global View hierarchy within the global spezi(_:) modifier.

This has several benefits:

• The component can inject arbitrary information or UI elements into the view hierarchy allowing for great flexibility.
• One can use arbitrary SwiftUI property wrappers within the Component. This might allow for easier state sharing (e.g. as a Binding) with subsystems of a component.
• Spezi's own property wrappers can make use of SwiftUI functionality (this point would motivate a out of the box conformance to ViewModifier).

Alternatives considered

Alternatives, where a Component provides a set of ViewModifiers (e.g. via a property wrapper similar to @Provide) were discussed. But generally those approaches reduce the flexibility or don't result in the same benefits as listed above. You wouldn't be able to use SwiftUI modifiers within your Component and it would increase the steps necessary to inject a view modifier into the view hierarchy.

Additional context

CC: @PSchmiedmayer

Code of Conduct

• [X] I agree to follow this project's Code of Conduct and Contributing Guidelines

[PSchmiedmayer]

Thank you @Supereg; I approve the ViewModifier approach as discussed in the meeting 🚀

[Supereg]

There is some content only suggesting that you want to avoid using classes for Views and ViewModifier (e.g. https://stackoverflow.com/questions/60321144/can-a-class-be-a-view-in-swiftui). We might need to investigate the true impact here, especially with ViewModifier.