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
AccountKey
implementation must always provideDataDisplay
andDataEntry
views 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?). ForAccountKey
of categorycredential
there is, due to the current implementation, a workaround to implementwriteOnly
account values (see here https://github.com/StanfordSpezi/SpeziAccount/pull/7#discussion_r1312385366). Status properties (likeemailVerified
) reported from account services also always need to implement aDataEntry
view.Solution
This issue propose a potential solution to this problem by allow to declare
DataDisplay
andDataEntry
types asEmptyView
s and adding respective documentation explaining the impact of such. The above-illustrated use cases would be resolved like the following:EmptyView
to theDataEntry
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 assupported
.EmptyView
to theDataDisplay
type. This would require additional code to exclude any write-only account values from theAccountOverview
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 theConfiguredAccountKey
methods if ...required
orcollected
, as they might only be configured assupported
.supported
as they would never show up in theAccountOverview
.Code of Conduct