-
Notifications
You must be signed in to change notification settings - Fork 926
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A top level forgiving validate method #146
Conversation
…tions for thousand, million, etc for the current language/culture or the passed language/culture. Added tests to validate.js for the same. Also ran grunt build after a successful grunt test call.
…hem there in the first place -.-
nice... I could use a method like this .. it seem logical if you can enforce a format be able to validate it what do you say @adamwdraper ? |
Oh and fyi, we are using this method in production already so its seen a lot of usage. |
Nice work. Thanks |
No problem. |
I was looking something like this to validate data in our application. Thanks! |
any plan to add this to the distro ? |
Numeral.js is quite forgiving and very fault tolerant. This can be seen quite evidently in methods like
unformat
. For example:In the examples above we can notice that Numeral.js is very fault tolerant and forgiving. But that makes it quite hard, for example, to visually guess what
unformat
might return.More often than not, we need to be able to soft validate numerals before, say, unformatting them. This is required so that we can make educated guesses about the values that a method like
unformat
returns while debugging.I came across multiple scenarios where I wished there was a top-level validation function in Numeral.js that was made for Numeral.js. By this what I mean is, the validator returns
true
if the value that is passed to it matches the rules given in the currentnumeral.language()
. For example, it doesn't strictly validate if the thousand separator ( ',' comma for en-US) is placed after 3 digits from the unit position, etc. It just validates if the thousands separator is used and if used, then only before the decimal separator and not after. This is what I mean by soft validations.It enables the programmer to visually correlate the value returned by, for example
unformat
, and the value passed to it. By this what I mean is, if the programmer sees that:numeral.validate('$1,00.123', 'en')
istrue
then he can guess thatnumeral().unformat('$1,00.123')
will return100.123
.This, in my experience, can make debugging a lot easier when using Numeral.js heavily (especially if you're using it to help in localization/i18n).
Hence I've added a top-level method called
validate
to thenumeral
object that supports soft validations over theabbreviations
,currency
anddelimiters
properties in the object returned bynumeral.languageData()
. I have also added the tests for it intests/numeral/validate.js
.numeral.validate
Syntax:
numeral.validate( value[, culture/language] )
value
is the localized numeral string. example:$100,000.123
culture
orlanguage
is a language code understood bynumeral.language
. exampleen
.It is optional.
If not provided, then
numeral.validate
uses the current language which is given bynumeral.language()
.Example usage:
EDIT: The build seems to be breaking as
grunt-contrib-uglify@0.4.0
expectsnode >= 0.10.0
but the version used for the build isv0.8.26
. This is causingnpm install
to fail and hence the build to fail.