Picture this
You need to check if an element exists on a page, let's take a look at this example:
You have a list of cool bugs on your website, but you want to check if the ladybug element is present on a specific instance (maybe the user initially chooses a bunch of insects from a list)
function doesLadybugExist() {
return (document.getElementById("lady-bug"));
// This will either return the element, or null
}
This looks alright... but, this will either return the element, or it will return null, which is not wrong, but in this example its not desired, we want to see if the ladybug exists
Lady bugs are !! cool
function doesLadybugExist() {
return (!!document.getElementById("lady-bug"));
// This will either true if it exists, or false
}
Take a closer look and see the !!
This is great because it returns a boolean value for us to if the user likes ladybugs or not. Success!
But not so fast. How does this work?
A quick google search will tell you that !! does not exist in a java context. It is simply the ! operator used twice.
What this does is it converts a non-boolean to an inverted boolean, meaning any truthy values get evaluated to true, and any falsy values get evaluated to false (in a boolean context)
All values are truthy unless they are defined as falsy
Below are the values that are falsy in Javascript according to MDN
No. | Value |
---|---|
1. | false |
2. | null |
3. | undefined |
4. | 0 (note: the string '0' evaluates to true) |
5. | NaN |
6. | '' |
7. | document.all |
Using !! is a clean, and easy way of comparing the state of an element on your DOM against a boolean value without having to worry about type-casting and other conversion methods.
And, lastly, do not not leave a like and a unicorn ;)
Top comments (8)
Yes, it will work but ESLint will mark it as redundant negation. IMHO it is better to use
Boolean(...)
.ESLint is opinionated and only as good as its configuration...
Someone had to make the initial configuration and even put in time to build the rule. Perhaps digging into why they took the time to do this can provide an idea as to why double negation could present possible friction.
As someone pointed out below, using
!!
is less obvious at a glance and take mental effort to decipher meaning. Don't get me wrong, it's important to know about and to share with people! But the alternative of usingBoolean()
is certainly worth exploring rather than simply ruling out for no reason.imho, depends on how used you are to seeing it. I am not used to seeing
Boolean()
, so it causes more friction to me than!!
πAll in all, I think it's just another way to do something in the already rather ambiguous JS language, and I'd put it right in line with
for..of
vs.forEach()
or the usage of semicolons. There's arguments on both sides and it comes down to the person writing the code.Whenever I do a code-review and see either, I just skip it for that very reason, if there are no strong arguments for using exactly one of them.
We have the same behavior in PHP. I really dislike this syntax.
It's unclear and you have to think too much in order to get what the developer meant.
Also, KISS ! It should be simple, and if you want a Boolean, simply cast it to a Boolean using the dedicated methods
100% not a good plan. Values are already truethy or falsey. Narrowing your data down to booleans using coercion is wasted effort and a practice which I suppose avoids side effects with no actual gain. I can appreciate that it's easier to comprehend that true is true and false is false, but knowing what is falsey and what is truethy in JavaScript at a language level is far more valuable.
I appreciate your passion for the idea and I see that you want clean code which is commendable, I know that I once fell for such seductive techniques. But my mentor at the time taught me the value of clean code Vs understandable code and if you have to think about anything not not being what it is then it's not not not good.
Your code has one bracket too many in the return statement in both code snippets.
Thanks i edited the post!