1

I quite regularly see some code like this:

const a = !!b && b.c === true;

I suppose the idea is to not have the a variable nullable, but in that case what is the difference with this code:

const a = b?.c === true

Is there a fundamental difference in between the two?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Léo Schneider
  • 2,085
  • 3
  • 15
  • 28
  • 3
    The first one works before [TypeScript 3.7](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#optional-chaining)? – jonrsharpe Mar 11 '20 at 08:25
  • https://stackoverflow.com/questions/784929/what-is-the-not-not-operator-in-javascript – Aleksey L. Mar 11 '20 at 08:36
  • The canonical question is *[What is the !! (not not) operator in JavaScript?](https://stackoverflow.com/questions/784929/)*. With 50 answers. – Peter Mortensen Aug 05 '22 at 11:46
  • Does this answer your question? [What is the !! (not not) operator in JavaScript?](https://stackoverflow.com/questions/784929/what-is-the-not-not-operator-in-javascript) – Samathingamajig Aug 05 '22 at 15:26

3 Answers3

1

This is more a JavaScript side of a problem...

The && operator returns the first falsy value, so 0, '', undefined, NaN or null would be the value of const a. If you want a boolean then the !! syntax is the most common way to ensure it being a Boolean.

If I'm not completely wrong on this the optional chaining (?.) just stops the execution on undefined or null values and returns undefined.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ch3micaL
  • 311
  • 1
  • 15
  • Arguably `!!(b && b.c)` might be nicer… – deceze Mar 11 '20 at 09:07
  • bug potential as this would change the program logic from `b.c` needs to be equal to `true` to `b.c` needs to be truthy – Ch3micaL Mar 11 '20 at 13:39
  • True, though seeing this code I would assume the author is simply hyper vigilant about types instead of being more… dynamic Javascript-y about them. The difference between `true` and *truthy* probably wouldn't make a difference. Of course, if it does, then yes, you should rather use the explicit comparison. – deceze Mar 11 '20 at 16:19
  • In this case, `a` will always be the literal `true` or `false`, not "0, '', undefined, NaN or null " – Samathingamajig Aug 05 '22 at 15:36
0

If the situation is such that b, if it exists (isn't undefined or null), will be an object, then no, there isn't any difference between those two.

The largest reason why you probably see someVar && someVar.someProp (or !!someVar && someVar.someProp) and variations is that optional chaining is pretty new syntax. It will only exist in recently-updated codebases (running TypeScript 3.7 or above).

But if a variable may be falsy, but is not necessarily an object - for example, if it's 0, NaN, false, or the empty string, then those constructs are not equivalent. Optional chaining with ?. will short-circuit to undefined only if expression to the left of the ?. is null or undefined. Other falsy values will continue to have their properties be evaluated as normal.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
CertainPerformance
  • 356,069
  • 52
  • 309
  • 320
0

Both expressions have the same result.

The crucial difference is: compatibility

In pure JavaScript, the ?. operator is really recent: See the Browser compatibility chart on MDN. My current browser, for example, (today is 2020-03-11, and my Linux system is running Firefox 73) does not support the b?.c syntax.

The b?.c === true version could simply not be written before ES2020 and will not work as is on your client's browser if he/she hasn't updated to recent builds to this day: "recent" would mean "bleeding edge"...

As mentioned by jonrsharpe in his comment, the ?. operator is also available through transpiled languages (TypeScript, CoffeeScript, Babel, etc.), with various dates of support.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
LeGEC
  • 46,477
  • 5
  • 57
  • 104