Re: [w3c/payment-request] WIP - very rough sketch of requestShippingAddress() method (#873)

danyao commented on this pull request.



> +            follows:
+          </p>
+          <ol class="algorithm">
+            <li>Let |event:PaymentMethodChangeEvent| be this
+            {{PaymentMethodChangeEvent}} instance.
+            </li>
+            <li>If |event|'s {{ Event.isTrusted }} attribute is false, then
+            return <a>a promise rejected with</a> an {{"InvalidStateError"}}
+            {{DOMException}}.
+            </li>
+            <li>Let |request:PaymentRequest| be the value of |event|'s
+            [=Event/target=].
+            </li>
+            <li>Assert: |request| is an instance of {{PaymentRequest}}.
+            </li>
+            <li>If |request|.<a>[[\state]]</a> is not "<a>interactive</a>",

Thanks @marcoscaceres for helping to think this through. I agree that it doesn't make sense to call `requestBillingAddress()` after `updateWith()` because the request may not be interactive by then.

I think multiple calls should be allowed if they form a promise chain. For example, maybe a merchant wants to iteratively calculate taxes based on country then region.

Either way, @rsolomakhin's suggestion to scope the two new methods to within `updateWith()` makes sense. I can't think of a use case that would necessitate calling the request*Address() method before and outside updateWith().

I adjusted the examples and algorithms. PTAL.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/pull/873#discussion_r342399133