Re: [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457)

`<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