-
Notifications
You must be signed in to change notification settings - Fork 662
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
[MOBILESDK 2683] Request for feedback on approach: Set As Default Payment Method Element in AddCard #10129
Conversation
Diffuse output:
APK
DEX
ARSC
|
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 think this approach is sound but I would be curious what the rest of the team thinks of the tradeoffs. It might make more sense for logic maintainability if these two were combined into one element.
data class SetAsDefaultPaymentMethodElement( | ||
val initialValue: Boolean, | ||
val shouldShowElementFlow: StateFlow<Boolean> | ||
): FormElement { |
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 probably doesn't make sense as a data class
since we are passing a StateFlow
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 assume that it should be a normal class instead then
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.
Yup! That way we don't generate the additional equals
and copy
methods.
...ents-ui-core/src/main/java/com/stripe/android/ui/core/elements/SavePaymentMethodElementUI.kt
Outdated
Show resolved
Hide resolved
} | ||
|
||
|
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 think the approach is sound. It has its upsides and tradeoffs.
- Don't need to create a combined element for managing the
Save for future
andSet as default
checkboxes. - Spacing remains controlled by
FormUI
.
Tradeoffs here are that the element is not a serializable element and is coupled to the state of whatever decides to show the element (in this case SaveForFutureElement
). It would make it harder to parcelize form elements if we need to though I imagine we would be serializing the values rather the elements themselves.
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 agree that this approach lgtm! I do think we only care about serializing the values -- when do we parcelize the form elements themselves @samer-stripe?
Summary
Adding Set As Default Payment Method Element
Looking for feedback on my approach
Motivation
https://jira.corp.stripe.com/browse/MOBILESDK-2683
Testing
N.A.
Screenshots
N.A.
Changelog
N.A.