- 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