- From: Marcos Cáceres <notifications@github.com>
- Date: Sun, 20 Jan 2019 22:12:13 -0800
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 21 January 2019 06:12:36 UTC
@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