Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ABW-3959] Factor Source Card component #1402

Merged
merged 15 commits into from
Dec 3, 2024

Conversation

danvleju-rdx
Copy link
Contributor

@danvleju-rdx danvleju-rdx commented Nov 29, 2024

Jira ticket: ABW-3959

Description

Adds reusable and configurable factor source card component

Video

Simulator.Screen.Recording.-.iPhone.16.-.2024-11-29.at.15.37.24.mp4

Copy link
Contributor

@matiasbzurovski matiasbzurovski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very clean! added some suggestions

@@ -1792,6 +1792,52 @@ internal enum L10n {
}
}
internal enum FactorSources {
internal enum Card {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guessing we don't have them on localisation repo yet due to issues with integration?

// MARK: - WarningErrorView
struct WarningErrorView: View {
// MARK: - StatusMessageView
struct StatusMessageView: View {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@@ -0,0 +1,77 @@
// MARK: - FactorSourceCardDataSource
struct FactorSourceCardDataSource {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really nice that you followed AccountCard approach

onRemoveTapped: onRemoveTapped
)
case let .instanceRegular(factorSource):
guard let details = factorSource.factorSourceKind.details else { return nil }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as mentioned on demo, I don't think the validation of which cards can be built should be made based on details, icon or title available. Instead, we would have a var isSupported: Bool or similar done at first, and have icon, title and details always return required values.

Once that change is done, the only difference between instanceCompact & instanceRegular would be showing a subtitle or not. I would then recommend one of the two following solutions:

enum Kind {
	case genericDescription(FactorSourceKind)
	case instance(factorSource: FactorSource, showDetails: Bool)
	case instanceLastUsed(
		factorSource: FactorSource,
		accounts: [Account] = [],
		personas: [Persona] = []
	)
}

or

enum Kind {
	case genericDescription(FactorSourceKind)
	case instance(factorSource: FactorSource, kind: InstanceKind)
	
	enum InstanceKind {
		case short(showDetails: Bool)
		case extended(accounts: [Account] = [], personas: [Persona])
	}
}

I like this last idea better because, as you see on the switch that iterate over the Kind, the instance cases are mostly repeated.

Comment on lines 278 to 281
case let .instanceCompact(factorSource),
let .instanceRegular(factorSource),
let .instanceLastUsed(factorSource, _, _):
factorSource.factorSourceKind
Copy link
Contributor

@matiasbzurovski matiasbzurovski Nov 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would change to

Suggested change
case let .instanceCompact(factorSource),
let .instanceRegular(factorSource),
let .instanceLastUsed(factorSource, _, _):
factorSource.factorSourceKind
case let .instance(factorSource, _)
factorSource.factorSourceKind

var accounts: [Account] = []
var personas: [Persona] = []

var hasAccountsOrPersonas: Bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would name this hasEntities or hasAnyAccountsOrPersonas

(because hasAccountsOrPersonas sounds like something which would return an enum)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hasEntities sounds good

@@ -96,7 +96,15 @@ extension FactorSource {
lastUsedOn: .now,
flags: []
),
hint: DeviceFactorSourceHint(name: name, model: "iPhone", mnemonicWordCount: .twentyFour, systemVersion: nil, hostAppVersion: nil, hostVendor: nil)
hint: DeviceFactorSourceHint(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a .sampleValue ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, DeviceFactorSourceHint does not have sample values exposed to hosts

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should export it

Copy link
Contributor

@GhenadieVP GhenadieVP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just some comments around the handling of not yet support factor source kinds.

}

extension FactorSourceKind {
var icon: ImageResource? {
Copy link
Contributor

@GhenadieVP GhenadieVP Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is optional because we don't have examples of icon for .trustedContact, .securityQuestions? Or because these should not have an icon?

Same for the rest, I would put a fatal error instead of returning nil, if the reason is just that we miss icon and so on.


switch kind {
case let .genericDescription(factorSourceKind):
guard let details = factorSourceKind.details else { return nil }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a factorSourceKind does not have details as per requirements or that we don't have these yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made details not optional

@GhenadieVP GhenadieVP merged commit b882dac into main Dec 3, 2024
6 checks passed
@GhenadieVP GhenadieVP deleted the ABW-3959-factor-instance-card-component branch December 3, 2024 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants