Currently, SpeziAccount houses a lot of components that are not specific to SpeziAccount and might be reused across other Spezi packages. Further, all API surfaces are currently exposed within a single target.
Solution
There might be Views or Infrastructure that either can
... be exposed as a separate target or ...
... be move to more general Spezi Packages (like Spezi or SpeziViews).
The following is a non-exhaustive list of components that can be moved out of SpeziAccount:
Validation: SpeziAccount currently ships with a fully customizable and fully abstract validation infrastructure. This could be moved into an entirely new Spezi package or into SpeziViews. This includes views like the ValidationResultsView and the VerifiableTextField.
Further, one could split up SpeziAccount into multiple targets. A potential distribution could look as follows:
Separating interfaces that are used by users of SpeziAccount from the API surface used by Account Service implementors.
Particularly one could structure it as follows:
AccountService (everything you need to build an account service)
Mock Account Service (depends on Account Service)
Account Module (only @_implementationOnly imports Mock Account for the previews, and imports AccountService while only exposing (not sure if @_implementationOnly would work there, otherwise we just normally import it which only results into a few types being exposed)
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
Currently, SpeziAccount houses a lot of components that are not specific to SpeziAccount and might be reused across other Spezi packages. Further, all API surfaces are currently exposed within a single target.
Solution
There might be Views or Infrastructure that either can
The following is a non-exhaustive list of components that can be moved out of SpeziAccount:
ValidationResultsView
and theVerifiableTextField
.Further, one could split up SpeziAccount into multiple targets. A potential distribution could look as follows:
Particularly one could structure it as follows:
Additional context
No response
Code of Conduct