-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
MBL-1969: Remove unused amount selector from NoShippingPledge flow #2247
Conversation
Generated by 🚫 Danger |
c198beb
to
dc12984
Compare
@@ -41,11 +41,6 @@ final class NoShippingPledgeViewController: UIViewController, | |||
|
|||
private var paymentSectionLabel: UILabel = { UILabel(frame: .zero) }() | |||
|
|||
private lazy var pledgeAmountViewController = { | |||
PledgeAmountViewController.instantiate() |
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.
pledgeAmountViewController
was no longer added to the view hierarchy in NoShippingPledgeViewController
- it was here, wired up, but invisible and unused.
var pledgeAmountSummaryViewHidden: Signal<Bool, Never> { get } | ||
var popToRootViewController: Signal<(), Never> { get } | ||
var processingViewIsHidden: Signal<Bool, Never> { get } | ||
var showApplePayAlert: Signal<(String, String), Never> { get } |
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 alert was only used to show information about pledge min/max issues. With the amount selector gone, the pledge can never be over/under on this page.
@@ -95,7 +90,6 @@ public class NoShippingPledgeViewModel: NoShippingPledgeViewModelType, NoShippin | |||
|
|||
let backing = project.map { $0.personalization.backing }.skipNil() | |||
|
|||
self.pledgeAmountViewHidden = context.map { $0.pledgeAmountViewHidden } |
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 did sometimes return false
but as mentioned, the pledgeAmountView
wasn't in the view hierarchy any more.
@@ -445,7 +407,7 @@ public class NoShippingPledgeViewModel: NoShippingPledgeViewModelType, NoShippin | |||
} | |||
|
|||
self.goToApplePayPaymentAuthorization = paymentAuthorizationData | |||
.takeWhen(goToApplePayPaymentAuthorization) | |||
.takeWhen(self.applePayButtonTappedSignal) |
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.
pledgeAmount
is now always valid, so an extra validation signal isn't needed here.
let isEnabled = Signal.merge( | ||
self.viewDidLoadProperty.signal.mapConst(false) | ||
.take(until: valuesChangedAndValid.ignoreValues()), | ||
valuesChangedAndValid, | ||
self.submitButtonTappedSignal.mapConst(false), | ||
createOrUpdateEvent.filter { $0.isTerminating }.mapConst(true) | ||
valuesChangedAndValid.takeWhen(didCreateOrUpdateBacking) |
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 found this small bug while running through the tests. The bug looked like this:
- Go to checkout
- Don't select a payment method. The CTA is disabled.
- Hit ApplePay
- ApplePay fails for some reason
- The CTA becomes enabled, even though there is no payment method selected still. That's because
createOrUpdateEvent
was always mapped totrue
.
This fixes that edge case.
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues([false]) | ||
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues( | ||
[true], | ||
"CTA is automatically enabled when you are updating the pledge." |
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.
Updated this test to reflect the actual page behavior. When you update your reward, you land on the checkout page with the CTA enabled. There's nothing to select on the checkout page to change the CTA state.
@@ -401,18 +354,23 @@ final class NoShippingPledgeViewModelTests: TestCase { | |||
self.configurePaymentMethodsViewControllerWithContext.assertValues([.changePaymentMethod]) | |||
|
|||
self.configurePledgeViewCTAContainerViewIsLoggedIn.assertValues([true]) | |||
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues([false]) | |||
self.configurePledgeViewCTAContainerViewIsEnabled.assertLastValue( | |||
false, |
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.
Per @ifosli suggestion, made a lot of these tests assertLastValue
instead of assertValues
.
|
||
let data = PledgeViewData( | ||
project: project, | ||
rewards: [reward], | ||
bonusSupport: 5.0, |
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.
For lots of these tests, I had to add back the bonusSupport
to the correct place. Before, the amount selector (even though it was hidden!) was echoing the selected bonus amount back to the view model.
b316808
to
902d481
Compare
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.
Looks good! I like what you did with the tests! If you haven't already, though, it might be good to just verify that the pledge flow still works as it should. (Ex: I'd probably test edit reward flow when actually changing the reward, edit reward when changing add-ons only, edit reward when just changing bonus support, change payment method, starting the pledge flow as a logged-out user.) But I think you were planning to wait to merge this anyways until after the release is cut, so I'm fine with just doing extra careful pledge-related testing as part of regression testing for the release after (potentially covering this pr and more).
@@ -2330,7 +2124,7 @@ final class NoShippingPledgeViewModelTests: TestCase { | |||
]) | |||
self.popToRootViewController.assertValueCount(1) | |||
self.showErrorBannerWithMessage.assertDidNotEmitValue() | |||
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues([false, false, true]) | |||
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues([false]) | |||
self.goToThanksProject.assertDidNotEmitValue() |
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 read through this test to understand why the true
disappeared (looks like that's because of the bug you fixed; I'm a little annoyed there was a test that tested wrong behavior) and my goodness some of these old tests really like to copy paste assertDidNotEmitValue
! Not an actionable thing for you (I don't think it's feasible to completely rewrite all our tests) but I didn't realize they were this tedious.
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, I didn't realize that easier! Definitely a big area for improvement. I remember testability came up in our retro for Pledge Management, and it's good to know there's a lot of room for improvement there.
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.
👍 and ➕1 to ingerid's comment about calling special attention to pledge regression tests in the next release.
Excellent callout about testing! Yes, I'll make sure this release has some extra regression testing - since we're going to merge other checkout improvements, too. As for this one, I've tested pledging as well as updating my pledge, both on staging and in prod, and it all looks good. |
📲 What
Remove unused amount selector from
NoShippingPledgeViewModel
andNoShippingPledgeViewController
.🤔 Why
The amount selector was used to update your bonus support on the checkout page of the pledge flow. In the no-shipping flow, that selector is moved to its own page. This means that all of the UI and VM code for the amount selector can be deleted from NoShippingPledge pages.
Removing this code improves the clarity of our
NoShippingPledgeViewModel
by deleting a fairly sized chunk of unused code. Fewer signals means better readability!🛠 How
I did this change in multiple stages: first tearing out the outputs, then the signal inputs, then the signals themselves. Fixing this also required cleaning up and fixing some of our checkout tests, many of which were no longer relevant to the no shipping flow.
Please see inline comments.