I have a viewModel with a bunch of numbers with lots of decimal places. If my bindings look like this:
<tr>
<td data-bind="text: Date"></td>
<td data-bind="text: ActualWeight"></td>
<td data-bind="text: TrendWeight"></td>
</tr>
Then, of course, the output has all the decimal places and is very unreadable. Changing the bindings to look like this solves the problem, but is very verbose and "noisy":
<tr>
<td data-bind="text: Date"></td>
<td data-bind="text: ActualWeight().toFixed(1)"></td>
<td data-bind="text: TrendWeight().toFixed(1)"></td>
</tr>
Note, this is one small snippet and having to add .toFixed(1) every place I bind a number leads to much more messy markup than what is shown here.
For everything except numbers, overriding the toString has been an effective way for me to control what the output looks like. Any suggestions on a way to tell knockout once, in some central way for my page what function to use to convert numbers into strings before they are added to the output?
For that matter, having a general purpose way to tell knockout how to format any type of value seems like it would be useful. Overriding Date.prototype.toString works but feels a little heavy handed since it may impact other uses of .toString besides just knockout's.
To build upon the accepted answer above. I forked RP Niemeyers fiddle to add comma formatting as well. So, if you have 10001.232 this will format as 10,001.232. Pretty important if you're working with prices. Again, this is just building on the answer.
JSFiddle
There are a couple of ways that you can handle a situation like this one. You can either choose to address it through bindings or push it into your view model.
If your view model is created by the mapping plugin and you don't want to get into customizing the way that it is created, then you can consider using a custom binding that is a wrapper to the text binding to handle the formatting.
Something like (http://jsfiddle.net/rniemeyer/RVL6q/):
It certainly would be possible to create an even more generic binding (formattedText) that either inspected the value and formatted it using some overridable defaults or allowed you to pass in some formatting options (
{ type: "numeric", precision: 2 }
).For your scenario, it sounds like the first option might be a good choice. However, if you want to push it into your view model, then you could create a special observable that can return both a formatted and a raw version of the value.
It could be something like (http://jsfiddle.net/rniemeyer/fetBG/):
Now you could potentially bind against
myValue
andmyValue.raw
depending on your needs. Otherwise, you could flip it and return the raw value by default and expose aformatted
dependentObservable. When an object like this is converted to JSON, it will lose any of the "sub-observables", so if you are sending this data back to a server that might be a consideration.You could again make it more generic and create a
formattedObservable
that takes in some information about how to format the object.Finally, 1.3 beta offers an
extenders
API. You could do something similar to above like: (http://jsfiddle.net/rniemeyer/AsdES/)Then, apply it to an observable like:
var myValue = ko.observable(1.223123).extend({numeric: 1});
You could have the extender also just add a
formatted
dependentObservable totarget
instead of returning the dependentObservable itself.Since knockout now supports extenders, I would use them instead of custom bindings. The binding would look something like this:
You have to write the
format
extender in this case. Examples are provided in the knockout documentation.To format currency and percent I have created my custom binding numeralformat.js to be used with numeral.min.js found at http://adamwdraper.github.com/Numeral-js/
numeralformat.js (Inspired by dateformat.js and moment.min.js)
Examples of bindings in View.
I approached formatting using jQuery Globalize plug-in. Here is my version of formatting handlers,
textFormatted
andvalueFormatted
are wrappers for text and value bindings respectively.Usage will be:
Optionally, culture can be specified as well. But I think this kind of control should not belong to HTML, although it can be helpful during developing or debugging time...
Values for
pattern
property/binding must be any of suitable formats thatGlobalize.format( value, format, [locale] )
function'sformat
param expects. Same goes forculture
property/binding that will be used in optionallocale
param. Globalize reference.Binding definitions: