Re: [w3c/browser-payment-api] Use navigator.payments singleton, factory method, or PaymentRequest constructor (#16)

Here are my thoughts on this issue.

I interpret singleton in this context to mean that we use the same object for each payment request. This would mean that, if `navigator.payments` is the singleton object, then you could write `navigator.payments.addEventListener(…)` and this would fire for all payment requests.

The problem with this pattern is that you have to understand how to reset a payment request. Currently the PaymentRequest object is a one-time deal. The state transitions show that you end up in closed and there are no state transitions leading back to earlier states. Reusing objects for new requests has been a source of interop problems in the past (e.g., with XHR) and we should keep this simple and avoid object reuse. This means we should not have a singleton for a payment request.

I can live with a factory method if that is really what people want. This could be `navigator.createPaymentRequest()` or `PaymentRequest.create()`. In my mind, factory methods are useful in two key scenarios. 1) When creating an instance of the object binds that object to some internal state that isn't exposed to calling code. The factory method implicitly retrieves that state and binds it to the instance; or 2) when the creation of the object causes some significant processing to occur. The factory method makes it clear in that case that this isn't simple object creation.

For our API, the constructor simply validates its arguments. It creates an instance with the validated arguments. It seems fine to use a constructor in this way. There are plenty of types in the browser type system that use constructors today and we've been moving away from unnecessary factory patterns in recent times (e.g. Events). This was the reason we moved to a constructor in the original proposal.

I would object to using a singleton but otherwise we should just decide quickly and make this issue go away. I don't see a need to change but if there is a quick consensus to do something else then we should do that now. Otherwise this is just bikeshedding and adding uncertainty to implementation.


---
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/browser-payment-api/issues/16#issuecomment-217178545