Indeed, “chained ternaries” is a better way to refer to them and I will start immediately.
From the article, “People try to use ternary statements as if they’re if statements. That doesn’t work, because ternary expressions are expressions, not statements”.
^ Actually, it does work with a little help from `||` or `&&`, which can and does lead to some logic errors.
Just today I put a PR on module with 500k daily installs, that broke it’s UMD wrapper due to an oversight surely from using “nested ternary statements”:
```
function (global, factory) {
typeof exports === 'object' && typeof module !== 'undefined'
? module.exports = factory(global)
: typeof define === 'function' && define.amd
? define(factory) : null
}
```
^ Muck
Yeah, that defeats the point of ternary expressions.
This should use if statements instead, to clarify the mutation intent.
If you're not capturing/returning the value of a ternary expression, you're missing the point of ternaries.
I included the snippet only to highlight how, in the real world, ternaries are used to execute statements rather than simply express values. FWIW, in this case, the final `null` needs to be replaced with `factory(global)` to work as expected.
Indeed, “chained ternaries” is a better way to refer to them and I will start immediately. From the article, “People try to use ternary statements as if they’re if statements. That doesn’t work, because ternary expressions are expressions, not statements”. ^ Actually, it does work with a little help from `||` or `&&`, which can and does lead to some logic errors. Just today I put a PR on module with 500k daily installs, that broke it’s UMD wrapper due to an oversight surely from using “nested ternary statements”: ``` function (global, factory) { typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory(global) : typeof define === 'function' && define.amd ? define(factory) : null } ``` ^ Muck