Closed marcoscaceres closed 2 years ago
You could use :
separated values perhaps, something like 2:USD:2
for 2 cents to pack it into one field ? Shrug.
I'm not really a fan of a single field unless it is an object.
Yeah, agree… that’s also not great, as then you need to remember what each position means. I.e., is the scale at index 0 or 2?
I think it’s probably best to leave this as is. It’s good to capture this discussion though, in case it comes up again.
Closing.
The asset amount and assetScale could be combined, but this has internationalization issues: decimal points, etc. are represented/formatted differently across different cultures, so it's probably safer to leave them separate and allow developers to combine them and present them based on the user/site's localization settings.
The payment request spec simply uses value/currency: https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value
They used a decimal format that simply uses a period as a decimal point. This format should present no more challenge to localizing than having to do calculation with an amount integer and assetScale
While dictionary
might not work as an event attribute (see #16), a custom interface would
[SecureContext, Exposed=Window]
interface MonetizationAmount {
readonly attribute DOMString value;
readonly attribute DOMString currency;
};
[SecureContext, Exposed=Window]
interface MonetizationEvent : Event {
constructor(DOMString type, MonetizationEventInit eventInitDict);
readonly attribute MonetizationAmount amount;
Raised elsewhere, it may be worth looking at consolidating amount/assetCode/assetScale into a single member. E.g.,:
"USD0.001"
However, that has several draw backs:
A developer would have to parse out the "assetCode", should they want to display an icon or currency symbol for it (ADA as ₳). The currency code is not guaranteed to be, for example, 3 letters and it maybe itself contain numbers (e.g., KP3R). That would make it quite error prone to parse out.
The asset
amount
andassetScale
could be combined, but this has internationalization issues: decimal points, etc. are represented/formatted differently across different cultures, so it's probably safer to leave them separate and allow developers to combine them and present them based on the user/site's localization settings.