-
Notifications
You must be signed in to change notification settings - Fork 12
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
Client handles payment method change #4
Conversation
trcoffman
commented
Nov 22, 2021
- Make the client of the library handle payment method changes
- Clean up the test suite
- Remove storing of credit and debit details from the PaymentRequest
We are no longer changing behavior for how PaymentRequest handles its details constructor argument, so the test changes from PR #1 are no longer valid. Revert these. There is a better way of changing PaymentRequestUpdateEvent, so revert all the changes from PR #1 and then re-do the tests in a following commit.
…vent names the same. In PaymentRequestUpdateEvent, all we have changed is added a new option for what the event name can be called. The simplest way to make sure that the class behaves the same for all valid event names is to simply run the entire test suite for all valid event names. So rather than duplicate select tests and give our 'paymentmethodchange' event, just use forEach to run the entire test suite for all valid event names.
@@ -158,7 +152,7 @@ export default class PaymentRequest { | |||
// 6. If the displayItems member of details is present, then for each item in details.displayItems: | |||
validateDisplayItems(details.displayItems, ConstructorError); | |||
|
|||
// 7. Let selectedShippingOption be null. | |||
// 7. Let selectedShippingOption and payment method be null. |
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 comment should not change because this isn't where i initialized _paymentMethod
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 looks great, the diff between upstream is looking a lot better.
The following can be done here or in follow-ups:
- Clean up exposing
PKPaymentMethodType${type}
in this PR or a quick follow-up. - The event structure for payment method change. The comment is wrong at the very least, but not sure if there's more guidance in the spec about what the structure/values should be.
}).toThrow(); | ||
}); | ||
}); | ||
['shippingaddresschange', 'shippingoptionchange', 'paymentmethodchange'].forEach((eventName) => { |
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.
💯