With amp-bind there's a clear need for formatting of strings. amp-bind supports string concatenation natively and some number formatting (e.g., round()) but nothing advanced.
One obvious use case is formatting numbers. 250 * 1000.25 should be displayable as 250,062.50. There are some tricks, like round(num * 100) / 100 to round to decimal places, and toPrecision(), but it can get complicated quickly. Also, I can't think of a way to do ,'s offhand.
It's not clear to me where this would be best contained. Mustache seems logical, but:
Alternatively, amp-bind could support a sprintf() expression. There is javascript sprintf code that appears fairly light.
Alternatively, it might make sense to (also?) expose the javascript Intl object, which gets you the basic number and data formatting, and probably covers 95% of the formatting use cases.
Thanks for the filing this issue James. Do you have a concrete use case in mind so we can scope this FR appropriately?
Related: #7978
My specific use case for this is that I tried to make a calculator in AMP, specifically a mortgage calculator. This is a use case for financial service providers (e.g., lending tree).
I built a proof of concept in AMP but the number output formatting isn't great:

(There should be a comma between 21 and 719, and a 0 after the .1 -- at least for me since I'm in the US.)
I could probably use toFixed() to solve for the decimal point issue, but that's a pain, and doesn't solve for the thousands separators.
Considering that amp-bind supports math, I see a general need to format the output. I also think it makes sense to consider how this might work for more broad use cases such as date formatting (e.g., with the new amp date picker I could see use cases where the user picks a date and you want to display it back to the user in a different format, like flight searches (Thurs Jan 9 - Mon Jan 13 instead of 1/9/2017 - 1/13/2017).
I agree that there is a need for a number/currency/date/time formatting feature. Also, it needs to be localized to make sense. For instance, USD 1234567.89, would in US English be formatted as "$1,234,567.89", in Spanish as "1.234.567,89 USD" and in French as "1 234 567,89 USD".
This feature should probably leverage the Unicode CLDR data similarly to e.g FormatJS or Globalize.
number_format would be a nice addition, I'm trying to comma delimit totals into a much more readable presentation layer ie.
拢6500 -> 拢6,500
This issue hasn't been updated in awhile. @choumx Do you have any updates?
Previously, I could not come up with a short macro like PHP number_format(), and finally... this is only one amp-bind-macro:
<amp-bind-macro id="formatNumber" arguments="value,fixed,point,thous" expression="(value<0?'-':'')+(abs(value)||0).toFixed(fixed||0).split('.').map((v,i)=>i?v:v.split('').map((v,i,a)=>(i&&(a.length-i)%3==0?thous||',':'')+v).join('')).join(point||'.')"></amp-bind-macro>
Pretty expression:
( value < 0 ? '-' : '' ) +
( abs( value ) || 0 )
.toFixed( fixed || 0 )
.split( '.' )
.map( ( v, i ) => i
? v
: v.split( '' )
.map( ( v, i, a ) => (
i && ( a.length - i ) % 3 == 0
? thous || ','
: ''
) + v
)
.join( '' )
)
.join( point || '.' )
Arguments:
value: Number or numeric string, default 0;
fixed: number of decimal points, default 0;
point: separator for the decimal point, default dot ".";
thous: thousands separator, default comma ",".
In Mustache template use simply:
<span [text]="'$' + formatNumber({{amount_in_usd}}, 2)"></span>
Most helpful comment
My specific use case for this is that I tried to make a calculator in AMP, specifically a mortgage calculator. This is a use case for financial service providers (e.g., lending tree).
I built a proof of concept in AMP but the number output formatting isn't great:
(There should be a comma between 21 and 719, and a 0 after the .1 -- at least for me since I'm in the US.)
I could probably use toFixed() to solve for the decimal point issue, but that's a pain, and doesn't solve for the thousands separators.
Considering that amp-bind supports math, I see a general need to format the output. I also think it makes sense to consider how this might work for more broad use cases such as date formatting (e.g., with the new amp date picker I could see use cases where the user picks a date and you want to display it back to the user in a different format, like flight searches (Thurs Jan 9 - Mon Jan 13 instead of 1/9/2017 - 1/13/2017).