Asked  6 Months ago    Answers:  5   Viewed   48 times

I am trying to compare a value coming from a HTML text field with integers. And it works as expected. Condition is -

x >= 1 && x <= 999;

Where x is the value of text field. Condition returns true whenever value is between 1-999 (inclusive), else false. Problem is, that the value coming from the text field is of string type and I'm comparing it with integer types. Is it okay to have this comparison like this or should I use parseInt() to convert x to integer ?



Because JavaScript defines >= and <= (and several other operators) in a way that allows them to coerce their operands to different types. It's just part of the definition of the operator.

In the case of <, >, <=, and >=, the gory details are laid out in §11.8.5 of the specification. The short version is: If both operands are strings (after having been coerced from objects, if necessary), it does a string comparison. Otherwise, it coerces the operands to numbers and does a numeric comparison.

Consequently, you get fun results, like that "90" > "100" (both are strings, it's a string comparison) but "90" < 100 (one of them is a number, it's a numeric comparison). :-)

Is it okay to have this comparison like this or should I use parseInt() to convert x to integer ?

That's a matter of opinion. Some people think it's totally fine to rely on the implicit coercion; others think it isn't. There are some objective arguments. For instance, suppose you relied on implicit conversion and it was fine because you had those numeric constants, but later you were comparing x to another value you got from an input field. Now you're comparing strings, but the code looks the same. But again, it's a matter of opinion and you should make your own choice.

If you do decide to explicitly convert to numbers first, parseInt may or may not be what you want, and it doesn't do the same thing as the implicit conversion. Here's a rundown of options:

  • parseInt(str[, radix]) - Converts as much of the beginning of the string as it can into a whole (integer) number, ignoring extra characters at the end. So parseInt("10x") is 10; the x is ignored. Supports an optional radix (number base) argument, so parseInt("15", 16) is 21 (15 in hex). If there's no radix, assumes decimal unless the string starts with 0x (or 0X), in which case it skips those and assumes hex. Does not look for the new 0b (binary) or 0o (new style octal) prefixes; both of those parse as 0. (Some browsers used to treat strings starting with 0 as octal; that behavior was never specified, and was [specifically disallowed][2] in the ES5 specification.) Returns NaN if no parseable digits are found.

  • Number.parseInt(str[, radix]) - Exactly the same function as parseInt above. (Literally, Number.parseInt === parseInt is true.)

  • parseFloat(str) - Like parseInt, but does floating-point numbers and only supports decimal. Again extra characters on the string are ignored, so parseFloat("10.5x") is 10.5 (the x is ignored). As only decimal is supported, parseFloat("0x15") is 0 (because parsing ends at the x). Returns NaN if no parseable digits are found.

  • Number.parseFloat(str) - Exactly the same function as parseFloat above.

  • Unary +, e.g. +str - (E.g., implicit conversion) Converts the entire string to a number using floating point and JavaScript's standard number notation (just digits and a decimal point = decimal; 0x prefix = hex; 0b = binary [ES2015+]; 0o prefix = octal [ES2015+]; some implementations extend it to treat a leading 0 as octal, but not in strict mode). +"10x" is NaN because the x is not ignored. +"10" is 10, +"10.5" is 10.5, +"0x15" is 21, +"0o10" is 8 [ES2015+], +"0b101" is 5 [ES2015+]. Has a gotcha: +"" is 0, not NaN as you might expect.

  • Number(str) - Exactly like implicit conversion (e.g., like the unary + above), but slower on some implementations. (Not that it's likely to matter.)

  • Bitwise OR with zero, e.g. str|0 - Implicit conversion, like +str, but then it also converts the number to a 32-bit integer (and converts NaN to 0 if the string cannot be converted to a valid number).

So if it's okay that extra bits on the string are ignored, parseInt or parseFloat are fine. parseInt is quite handy for specifying radix. Unary + is useful for ensuring the entire string is considered. Takes your choice. :-)

And finally: If you're converting to number and want to know whether the result is NaN, you might be tempted to do if (convertedValue === NaN). But that won't work, because as Rick points out below, comparisons involving NaN are always false. Instead, it's if (isNaN(convertedValue)).

Tuesday, June 1, 2021
answered 6 Months ago

You're using arrow functions. IE11 doesn't support them. Use function functions instead.

Here's Babel's translation of that to ES5:

g.selectAll(".mainBars").append("text").attr("x", function (d) {
  return d.part == "primary" ? -40 : 40;
}).attr("y", function (d) {
  return +6;
}).text(function (d) {
  return d.key;
}).attr("text-anchor", function (d) {
  return d.part == "primary" ? "end" : "start";
Tuesday, June 1, 2021
answered 6 Months ago

Because JavaScript uses floating point math which can lead to rounding errors.

If you need an exact result with two decimal places, multiply your numbers with 100 before the operation and then divide again afterwards:

var result = ( 4990 % 10 ) / 100;

Round if necessary.

Wednesday, June 9, 2021
answered 6 Months ago

I was able to fix this issue by making browser sleep for few seconds after every change in URL.

Below is the code snippet:

67 it('should create new job listing', function () {
68        //Login As Admin To Access Vacancies Feature
69        loginAsManager();
.        //load manager's dashboard list page
.        dashboardPage = new DashboardPage();
.        //load vacancies list page
.        var vacanciesUrl = browser.baseUrl + '#/vacancies';
.        browser.sleep(2000);
.        expect(browser.getCurrentUrl()).toEqual(vacanciesUrl);
.        vacanciesPage = new VacanciesPage();

I don't think this is a neat solution to this problem.

I will be happy to hear, if someone has a better solution to this.

Cheers Gaurav

Friday, October 15, 2021
Morrison Chang
answered 2 Months ago

Maybe a dependency error. I'll suggest you to use a better practice for such lib.

  1. Put the fullcalendar scripts into vendor/assets/javascripts

  2. Require this script manually in application.js before the tree and after jquery and any other lib it depends.

    /=require 'fullcalendar`


Check the loaded Javascript files in header, if application.js is the last, you have dependency error. The lib must be there before calling it.

Thursday, November 11, 2021
Yuriy Faktorovich
answered 3 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :