- From: Marcos Cáceres <notifications@github.com>
- Date: Thu, 16 Mar 2017 22:25:20 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/issues/457/287270099@github.com>
`<rant>` I guess it doesn't matter too much, but in my *web developer* facing implementation of this API (i.e., this is not from a Browser Vendor's implementation perspective!) I have the following ES classes. ```JS class DisplayItem extends Localizable { /* stuff */ }; class PaymentShippingOption extends DisplayItem { /* stuff */ } class PaymentItem extends DisplayItem { /* stuff */ } ``` And then I have classes like `InventoryTable` (e.g., list of clothing items) and a `ShippingOptionsPicker` that expose a `displayItem` accessor property. ```JS class InventoryTable { get diplayItems() {/* returns PaymentItems */} } class ShippingOptionsPicker { get diplayItems() { /*returns the selected PaymentShippingOption */} } class TaxCalculator { get diplayItems() {/* returns PaymentItem representing the calculated tax, based on the above */} } ``` So, then a `TaxCalculator` can calculate tax by, amongst other things, accessing and summing the values of `.displayItems` from `InventoryTable ` and `ShippingOptionsPicker` (with some type assurance, based on the `DisplayItem` sub-class). Eventually, all the "display items" are gathered to produce the `.total` and line items sent to the `PaymentRequest` constructor. My point is that it's helpful to be able to reuse things in the spec in user land code. `</rant>` Thought I'd raise it for illustrative purposes. But closing because, meh :) -- 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/457#issuecomment-287270099
Received on Friday, 17 March 2017 05:26:17 UTC