-
Notifications
You must be signed in to change notification settings - Fork 42
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
[WIP] showPaymentUI() method #325
base: gh-pages
Are you sure you want to change the base?
Conversation
@rsolomakhin, @ianbjacobs PTAL |
}; | ||
|
||
partial interface Navigator { | ||
[SecureContext, SameObject] readonly attribute PaymentHandlerContainer paymentHandler; |
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.
If both navigator.paymentHandler
and navigator.paymentHandler.data
are not promises, then the browser has to initialize these objects very early in page load, which can affect page loading performance. Can we make at least one of these into a promise, so that the browser can lazy-instantiate them after the page has loaded?
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.
paymentHandler.data
should be a Promise, IMO. This seemed to work well with the Web Payment CG's original API design where the "payment request" could be retrieved via getPendingRequest
:
const paymentRequest = await navigator.payment.getPendingRequest();
// ... handle payment request, generate acknowledgement
// acknowledge payment request handled
navigator.payment.acknowledge(acknowledgement);
https://github.com/Spec-Ops/payment-polyfill#getting-a-pending-payment-request
Here it would be:
const data = await navigator.paymentHandler.data;
// ... handle payment request, generate response
// respond to payment request
navigator.paymentHandler.respondWith(response);
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.
Okay, I agree with this. I'll update this soon.
(I am going to defer to @rsolomakhin for the details!) |
</section> | ||
<section> | ||
<h2> | ||
<dfn>respondWith()</dfn> method |
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.
Does navigator.paymentHandler.respondWith(response)
need its own algorithm?
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 method simply passes the response data to SW thread. So, I thought that the method's explanation is enough.
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.
To help your understanding, I have a plan to implement POC for this idea. Do you think that it's useful?
}; | ||
|
||
partial interface Navigator { | ||
[SecureContext, SameObject] readonly attribute PaymentHandlerContainer paymentHandler; |
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.
Okay, I agree with this. I'll update this soon.
</section> | ||
<section> | ||
<h2> | ||
<dfn>respondWith()</dfn> method |
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 method simply passes the response data to SW thread. So, I thought that the method's explanation is enough.
@romandev : I agree that it might be useful to get implementation experience with this feature. Feel free to build it behind a flag. This can guide our discussions in W3C and we can also talk to the payment handler writers about trying out this part of the API. |
Can you please remove me from this thread?
Cece Cheam │ Executive Administrator to Ansar Ansari, SVP Digital Payment Products
Office: (650)432-5580 │Mobile: (415)542-8167 │ Email: scheam@visa.com<mailto:scheam@visa.com>
[https://insite.trusted.visa.com/content/dam/insite/news/Visa%20News/2017/June/email-signature/EmailSig-DynamicFlagVersion.png]
From: Rouslan Solomakhin <notifications@github.com>
Sent: Thursday, September 27, 2018 10:43 AM
To: w3c/payment-handler <payment-handler@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [w3c/payment-handler] [WIP] showPaymentUI() method (#325)
@romandev<https://github.com/romandev> : I agree that it might be useful to get implementation experience with this feature. Feel free to build it behind a flag. This can guide our discussions in W3C and we can also talk to the payment handler writers about trying out this part of the API.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#325 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQ8khq43l0EXLuNyUyGJLibfq_Qup-bLks5ufQ4zgaJpZM4W21YO>.
|
@@ -1192,6 +1192,7 @@ <h2> | |||
readonly attribute DOMString instrumentKey; | |||
readonly attribute boolean requestBillingAddress; | |||
Promise<WindowClient?> openWindow(USVString url); | |||
Promise<PaymentHandlerResponse?> showPaymentUI(USVString url, optional object? data = null); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
@@ -1192,6 +1192,7 @@ <h2> | |||
readonly attribute DOMString instrumentKey; | |||
readonly attribute boolean requestBillingAddress; | |||
Promise<WindowClient?> openWindow(USVString url); | |||
Promise<PaymentHandlerResponse?> showPaymentUI(USVString url, optional object? data = null); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
closes #299, #300
The following tasks have been completed:
Implementation commitment:
Preview | Diff