Currently, an AccountKey implementation must always provide DataDisplay and DataEntry views and an implementation has little to know control to specify if it is readOnly, writeOnly (e.g. only supply a verification code at signup) or readWrite (any other possibilities?).
For AccountKey of category credential there is, due to the current implementation, a workaround to implement writeOnly account values (see here https://github.com/StanfordSpezi/SpeziAccount/pull/7#discussion_r1312385366).
Status properties (like emailVerified) reported from account services also always need to implement a DataEntry view.
Solution
This issue propose a potential solution to this problem by allow to declare DataDisplay and DataEntry types as EmptyViews and adding respective documentation explaining the impact of such. The above-illustrated use cases would be resolved like the following:
Read-Only account values are declared by setting an EmptyView to the DataEntry type. Therefore, the never show up in the signup view (independent of their requirement level configured by the user) and might show up in the Account Overview if the user decides to configure the AccountKey as supported.
Write-Only account values are declared by setting an EmptyView to the DataDisplay type. This would require additional code to exclude any write-only account values from the AccountOverview view and only render these account values in the SignupView if configured by the user.
Additional context
It might make sense to add @available(*, deprecated, message: "...") annotations to the ConfiguredAccountKey methods if ...
... you want to configure a read-only account value as required or collected, as they might only be configured as supported.
... you want to configure a write-only account value as supported as they would never show up in the AccountOverview.
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
Currently, an
AccountKeyimplementation must always provideDataDisplayandDataEntryviews and an implementation has little to know control to specify if it isreadOnly,writeOnly(e.g. only supply a verification code at signup) orreadWrite(any other possibilities?). ForAccountKeyof categorycredentialthere is, due to the current implementation, a workaround to implementwriteOnlyaccount values (see here https://github.com/StanfordSpezi/SpeziAccount/pull/7#discussion_r1312385366). Status properties (likeemailVerified) reported from account services also always need to implement aDataEntryview.Solution
This issue propose a potential solution to this problem by allow to declare
DataDisplayandDataEntrytypes asEmptyViews and adding respective documentation explaining the impact of such. The above-illustrated use cases would be resolved like the following:EmptyViewto theDataEntrytype. Therefore, the never show up in the signup view (independent of their requirement level configured by the user) and might show up in the Account Overview if the user decides to configure the AccountKey assupported.EmptyViewto theDataDisplaytype. This would require additional code to exclude any write-only account values from theAccountOverviewview and only render these account values in the SignupView if configured by the user.Additional context
It might make sense to add
@available(*, deprecated, message: "...")annotations to theConfiguredAccountKeymethods if ...requiredorcollected, as they might only be configured assupported.supportedas they would never show up in theAccountOverview.Code of Conduct