search

WICG / digital-goods

Other
50 stars 28 forks source link

Consider rejecting promises from getDigitalGoodsService instead of returning null #23

Closed phoglenix closed 3 years ago

phoglenix commented 3 years ago

This would let the API return more informative error messages to the developer, which could optionally be handled programmatically e.g. if a payment method is unavailable, try another, but if we're not in a supported context, stop trying. It would also avoid spamming the JS console if errors were caught and handled (compared with the current way of exposing errors, which is to output to the JS console directly).

mgiuca commented 3 years ago

s/throwing errors/rejecting promises/ SGTM.

Is there currently any case where we reject the promise to getDigitalGoodsService?

phoglenix commented 3 years ago

Yep, I meant rejecting promises by throwing errors (seems to be the standard way). No, currently we never reject the promise to getDigitalGoodsService. Just return null if there are any issues.

rsolomakhin commented 3 years ago

Should we do both? For example, if the context does not support digital goods API, return null. If the context supports digital goods, but not with this payment method, then return NotSupportedError.

mgiuca commented 3 years ago

I would rather that we limit the number of things that clients have to check.

There are three levels of "unsupported" here:

  1. The UA does not support DG at all (we definitely have to account for this, since not all UAs in the foreseeable future will implement this API).
  2. The UA supports DG, but not in this context.
  3. The UA supports DG in this context, but not with this payment method.

Case 1 can only be handled by the non-existence of the getDigitalGoodsService method. You're proposing that Case 2 returns null and Case 3 rejects with NotSupportedError? Then developers need to have 3 separate checks (an existence check on getDigitalGoodsService, a try-catch around the call, and a null check on its result). I don't think it's really worth distinguishing Cases 2 and 3 (in fact I'm not really sure what the difference is). If we do want to distinguish them, we should reject with different errors so that if the developer doesn't care, they can just catch all exceptions.

phoglenix commented 3 years ago

I agree with mgiuca@. I think if the DG API is supported (ie. window.getDigitalGoodsService is defined) then it's more helpful to reject calls with a specific error than returning null to represent one of the failure cases.

phoglenix commented 3 years ago

This is fixed by v2.0 changes (https://github.com/WICG/digital-goods/pull/34)

MrVibe commented 2 years ago

I am stuck at this, getDigitalGoodsService

const PAYMENT_METHOD = "https://play.google.com/billing service = await window.getDigitalGoodsService(PAYMENT_METHOD);

shows Promise error "DOMException: unsupported context" , what could be possible reason ? the function getDigitalGoodsService is defined and testing in a TWA from Playstore.

azabraao commented 2 years ago

@MrVibe did you manage to solve it? I have the same issue. I think it's probably related to a PWA installed via Browser instead of via Play Store. So this is what the "unsupported context" would mean in this case.