Dinero({amount: 5000, currency: 'USD'})
.add(Dinero({ amount: 1000, currency: 'EUR'}))
...and then convert that sum to a concrete currency later.This feature request inspired by http://blog.ploeh.dk/2017/10/16/money-monoid/
Dinero({amount: 5000, currency: 'USD'})
.add(Dinero({ amount: 1000, currency: 'EUR'}))
...and then convert that sum to a concrete currency later.This feature request inspired by http://blog.ploeh.dk/2017/10/16/money-monoid/
If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, not a JavaScript library.
Also in my dream money library, division and multiplication would be done with whole number fractions like
new Dinero({amount: 1000, currency: ‘usd’})
.multiply({numerator: 1, denominator: 3 })
which can similarly be deferred to prevent rounding errors in partial calculations.I think generally you 'need to know' immediately.
Source: worked at a bank that implemented pretty much this.
Source: worked on multi-currency fund tracking software.
At larger scales even exchange rates are a leaky abstraction over a forex market, so there you go. No solution will work everywhere.
But if you’re entering the prices of last week’s coffee and hotel room into a web app to see how much you’ll be reimbursed, you don’t want to use a new exchange rate every time a form input changes.
Source: worked on multi-currency expense reporting software where everything is done in JavaScript floats.
This technique is fantastic for units that don’t change relations though, like mass and length.
> You must provide your own API to retrieve exchange rates.
https://sarahdayan.github.io/dinero.js/module-Dinero.html#~c...