-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Introduce IntegrationConfigurable #4081
Conversation
payload["form_sheet_action"] = formSheetAction.analyticValue | ||
payload["hide_mandate_text"] = hidesMandateText |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note these new embedded only params.
/// Represents shared configuration properties shared between integration surfaces in mobile payment element. | ||
/// - Note: See the concrete implementations of `IntegrationConfigurable` for detailed doc comments. | ||
/// - Note: Not currently used by CustomerSheet. | ||
protocol IntegrationConfigurable: PaymentMethodRequirementProvider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open to naming suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's call it PaymentElementConfiguration? I think that's the most accurate name, since this is Configuration for all Mobile Payment Element integration variants. We just need to start thinking of PaymentSheet, FlowController, EmbeddedPaymentElement as Payment Element variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means we should probably rename things like PaymentSheetLoader
to be PaymentElementLoader
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree on renaming other PaymentSheet prefixed classes, maybe something we should tackle when we rename the module.
🚨 New dead code detected in this PR: PaymentElementConfiguration.swift: warning: Property 'primaryButtonColor' is unused
PaymentElementConfiguration.swift: warning: Property 'primaryButtonLabel' is unused
PaymentElementConfiguration.swift: warning: Property 'style' is unused
PaymentElementConfiguration.swift: warning: Property 'merchantDisplayName' is unused
PaymentElementConfiguration.swift: warning: Property 'savePaymentMethodOptInBehavior' is unused
PaymentElementConfiguration.swift: warning: Property 'appearance' is unused
PaymentElementConfiguration.swift: warning: Property 'shippingDetails' is unused
PaymentElementConfiguration.swift: warning: Property 'preferredNetworks' is unused
PaymentElementConfiguration.swift: warning: Property 'userOverrideCountry' is unused
PaymentElementConfiguration.swift: warning: Property 'removeSavedPaymentMethodMessage' is unused
PaymentElementConfiguration.swift: warning: Property 'allowsRemovalOfLastSavedPaymentMethod' is unused Please remove the dead code before merging. If this is intentional, you can bypass this check by adding the label ℹ️ If this comment appears to be left in error, double check that the flagged code is actually used and/or make sure your branch is up-to-date with |
I initially thought the dead code check was confused, but it's not, it's correct! I can comment out all those properties on I added the skip dead code check b/c I feel the spirit of the protocol is to define the commonalities between config objects and even though those properties are not used yet they probably will be as we build out embedded. Options:
|
@@ -244,7 +244,7 @@ class CustomerAddPaymentMethodViewController: UIViewController { | |||
isSettingUp: true, | |||
countryCode: nil, | |||
savePaymentMethodConsentBehavior: savePaymentMethodConsentBehavior, | |||
analyticsHelper: .init(isCustom: false, configuration: .init()) // Just use a dummy analytics helper; we don't look at these analytics. | |||
analyticsHelper: .init(isCustom: false, configuration: PaymentSheet.Configuration.init()) // Just use a dummy analytics helper; we don't look at these analytics. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add https://jira.corp.stripe.com/browse/MOBILESDK-2548 to this comment
/// Represents shared configuration properties shared between integration surfaces in mobile payment element. | ||
/// - Note: See the concrete implementations of `IntegrationConfigurable` for detailed doc comments. | ||
/// - Note: Not currently used by CustomerSheet. | ||
protocol IntegrationConfigurable: PaymentMethodRequirementProvider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's call it PaymentElementConfiguration? I think that's the most accurate name, since this is Configuration for all Mobile Payment Element integration variants. We just need to start thinking of PaymentSheet, FlowController, EmbeddedPaymentElement as Payment Element variants.
let configuration: PaymentSheet.Configuration | ||
let configuration: IntegrationConfigurable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should keep this PaymentSheet.Configuration
? I'm not sure this class can reasonably also handle analytics for EMPE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah looking at the class more, it'll be pretty hard. We'll want some embedded specific one.
/// Represents shared configuration properties shared between integration surfaces in mobile payment element. | ||
/// - Note: See the concrete implementations of `IntegrationConfigurable` for detailed doc comments. | ||
/// - Note: Not currently used by CustomerSheet. | ||
protocol IntegrationConfigurable: PaymentMethodRequirementProvider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means we should probably rename things like PaymentSheetLoader
to be PaymentElementLoader
.
Summary
IntegrationConfigurable
which is a protocol that defines similarities betweenPaymentSheet.Configuration
andEmbeddedPaymentElement.Configuration
.IntegrationConfigurable
where currently neededPaymentSheet.Configuration
toIntegrationConfigurable
CustomerSheet.Configuration
toIntegrationConfigurable
as it's not currently needed. It might be in the future however.Motivation
Testing
Changelog
N/A