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

MBL-1969: Remove unused amount selector from NoShippingPledge flow #2247

Merged
merged 7 commits into from
Jan 27, 2025

Conversation

amy-at-kickstarter
Copy link
Contributor

@amy-at-kickstarter amy-at-kickstarter commented Jan 15, 2025

📲 What

Remove unused amount selector from NoShippingPledgeViewModel and NoShippingPledgeViewController.

🤔 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.

@nativeksr
Copy link
Collaborator

1 Warning
⚠️ Big PR

Generated by 🚫 Danger

@amy-at-kickstarter amy-at-kickstarter changed the title Feat/adyer/mbl 1969 MBL-1969: Remove unused amount selector from NoShippingPledge flow Jan 16, 2025
@@ -41,11 +41,6 @@ final class NoShippingPledgeViewController: UIViewController,

private var paymentSectionLabel: UILabel = { UILabel(frame: .zero) }()

private lazy var pledgeAmountViewController = {
PledgeAmountViewController.instantiate()
Copy link
Contributor Author

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 }
Copy link
Contributor Author

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 }
Copy link
Contributor Author

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)
Copy link
Contributor Author

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)
Copy link
Contributor Author

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 to true.

This fixes that edge case.

self.configurePledgeViewCTAContainerViewIsEnabled.assertValues([false])
self.configurePledgeViewCTAContainerViewIsEnabled.assertValues(
[true],
"CTA is automatically enabled when you are updating the pledge."
Copy link
Contributor Author

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,
Copy link
Contributor Author

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,
Copy link
Contributor Author

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.

@amy-at-kickstarter amy-at-kickstarter marked this pull request as ready for review January 16, 2025 15:21
Copy link
Contributor

@ifosli ifosli left a 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()
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@scottkicks scottkicks left a 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.

@amy-at-kickstarter
Copy link
Contributor Author

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.

@amy-at-kickstarter amy-at-kickstarter merged commit 9294c35 into main Jan 27, 2025
5 checks passed
@amy-at-kickstarter amy-at-kickstarter deleted the feat/adyer/mbl-1969 branch January 27, 2025 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants