When you retrieve an object value that’s undefined, it will crash due to a TypeError! So make sure you do an initial check with an if statement. ...
For further actions, you may consider blocking this person and/or reporting abuse
This is something you see a lot when stringing shell commands together.
This way of using
&&
before running a function (or command) and calling it a "guard operator" makes it seem like it's not what it actually is (an expression).It gets a little odd when you try to do things that seem to make sense on the face of it, like use an assignment instead of a final expression:
And it can be tempting to string too many of them together and make quite a confusing line.
I prefer to be explicit, and to dive out if the condition isn't met:
Maybe 'Gate' would be a better word?
Why would one prefer the
&&
operator over a conditional? At first glance, the later seems 'better' in many ways:if (x.y !== undefined)
x.y &&
will result in undefined ifx.y
isundefined
, rather than entering anelse
clauseIt's a one-liner, sure, but I would argue ternary operators are a better fit:
x.y ? f(y) : g()
over(x.y && f(y)) || g()
.Not saying you're wrong, but I'm curious about the reasoning.
I'm in agreement with those opposing this idiom. The Javascript phrase:
obj && obj.prop && obj.prop.send();
is an expression, and (to me at least) should be pure, like a pure function. As used above, this expression is used only for its side effect. I would always prefer to be explicit. I like the proposed optional chaining; but until that's available, write this statement in English:
// pedantic
if (obj && obj.prop && typeof obj.prop.send === 'function') {
obj.prop.send();
}
That’s the really interesting thing about JS or programming in general. There are always multiple ways of solving things. Some of them are definitely a syntactic choice. I’m always in the camp of expanding my toolkit so when I run across it (especially from others code), I know what’s going on. But at the end of the day, you’re the owner of your code, so pick the way that makes the most sense to you 😊
You could use OR defaulting to protect against Type Errors, too:
Or take this a step further and write a helper for this:
(iterative version)
(recursive version)
I typically use the “||” for setting the default values. Thanks for sharing your solution 🙂
Is it just me, or does it feel like the elvis operator will only enable us to be more negligent?
Nothing stops us writing
when what we really needed was
Which will make the code not "fail fast", even though there's no correct logic when the
a
has nob
or a presentc
has nod
.The currently possible code:
tells us a lot more about the structure. And it's not a token longer!
The main problem here is that a 3-level destructuring is seen as "showing off" most of the time, and (often correctly) shamed as "unreadable", here one can just say this is "defensive programming". Which it's not, since you are failing to throw valuable errors in the "safe" inner code.
So, I am sure there are genuine uses, I have many places in my code I'd like to use it myself, especially the
?.()
. But I fear it will be overused, and its overuse "well-justified".You’re absolutely right! It’s one of those common JS saying, just because you can doesn’t mean you should. When it’s used appropriately, it’s super helpful. And if you abuse it, it becomes a code smell. Definitely something to be careful of. Thanks for pointing that out 👍
That spicy proposal looks exciting. 'Elvis' operator is totally suited to javascript
Hahaha, I think I learned something new! Never knew that was called the ‘elvis’ operator 😂
I first heard it referred to as that when I was reading through a groovy scripting tutorial!
The Elvis operator
?:
returns left-hand side if it is trueish, right-hand side otherwise, thus comparable toobject || default
. groovy-lang.org/operators.html#_el...It is called Elvis because it looks like an Elvis emoticon, but I always memoized it with "Not sure if he still exists" :-)
OTOH, the safe-navigation operator
?.
will return left-hand side if it is null, otherwise evaluate right-hand side on the result of left-hand side, thus comparable toobject && object.prop
groovy-lang.org/operators.html#_sa...So the proposal for JavaScript is not the Elvis operator, but comparable to the safe-navigation operator.
Indeed! Yes, thanks for the correction. In my new blog post, I talk about the Elvis Operator and hopefully others won't make the same confusion as I had 😅
The issue comes when people chain up 5 at once and you get bogged down with the 4 or so properties before the one you're trying to get.
Much prefer lodashes
has
or object destructuring.I always felt using the && operator in this manner was an unintentional. And that its a quirk of JS. Like it should only be used in the if statement. Nevertheless it's super useful.
Definitely something to keep in your toolkit. Even if you don’t use it. If you ever come across that code, at least you will be able to follow what other people are trying to do 😊
Should recommend github.com/facebookincubator/idx