Re: [w3c/payment-request] fix: convert PaymentMethodData.data (#812)

@domenic, because in implementations, `PaymentMethod.data`'s JS-to-IDL conversion happens in the `PaymentRequest` constructor (instead of on `.show()`), it means we don't need the `[[serialized*]]` data internal slots because:

 * We can do the "JSON serializable" check at construction time and when `updateWith()` is called: this gives us assurances that `.data` doesn't contain any un-serializable JSON types and circular references....and, if ever needed, `.data` can be serialized to a string in the future. 
 * And because of the above, we can just internally hold *converted* IDL values for each PaymentRequest instance, without the need to hold them in string form.

This  also fixes what would otherwise be a mess when `show()`ing or `updateWith()`ing a payment sheet: the [[serializedModifierData]] array positions would need  to match the position of the deleted `.data` members. 

So, with this PR,  when a payment handler shows or gets updated, it always operates on its expected IDL type, without needing to redo any redundant JSON parsing, re-conversions, etc.

-- 
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/812#issuecomment-455959249

Received on Monday, 21 January 2019 06:12:36 UTC