Support for numbers as strings

[joeworkman]

This fixes #37

[codecov-io]

Codecov Report

Merging #38 into master will decrease coverage by 0.6%.
The diff coverage is 50%.

@@            Coverage Diff            @@
##           master     #38      +/-   ##
=========================================
- Coverage      98%   97.4%   -0.61%     
=========================================
  Files           3       3              
  Lines         201     154      -47     
=========================================
- Hits          197     150      -47     
  Misses          4       4

[deitch]

Having though about it again in line with the comment here on the issue, I think this does make sense, but should be narrowed. A general "treat all strings as numbers if they pass !isNaN()" is asking for trouble. What if someone wants to look at "0001" as a string, and not a number? They used a string intentionally.

On the other hand, if we limit it to just if someone tells searchjs to treat it as a number - we don't care why, they can declare it - then we have limited the scope and returned expected behaviour to user control.

Let's do the following:

1. Define a new modifier called _number which says, "treat this string field as number". Defaults to false, of course.
2. If _number === true, then we treat the field as a number, as you wanted to
3. Update the README to reflect it
4. Add some tests to show it both not treating "6.5" as a number if _number is not set, and treating it as a number if _number is set.

If we do that, then this all works well.

[deitch]

Define a new modifier called _number which says, "treat this string field as number". Defaults to false, of course. If _number === true, then we treat the field as a number.

1. Create the logic for this to limit the scope
2. Update the README to reflect it
3. Add tests to show it both not treating "6.5" as a number if _number is not set, and treating it as a number if _number is set.