Great post! I've recently started using ternary operators as well. One "gotcha" I've found when writing them is to not use them in a way that make the line-length too long. Typically I try and keep them under 80 characters, so you can also write your example like this if that was a goal:

let userIdValid = (userId.value.length === 10) ? 
  "the user ID is valid" : 
  "the user ID is not valid";

Thanks for the post!

You might want to use a different example where the variable is of a different type than boolean, e.g.:

let msg = (userId.value.length === 10) ? 'length 10' : 'other length'

Because if the variable itself is a boolean, why not just say:

let userIdValid = userId.value.length === 10

Given that === already produces true or false the examples are a bit redundant. :)

Here's another operator taking three operands: a(b, c).

In my view the insight that is missing in this article is the key difference between both conditional constructs:

• An if statement is - well, a statement.
• The ternary operator is part of an expression.

So what?

• An if statement routes the flow of execution - based on the outcome of the condition, program execution is routed to a specific conditional block of statements.

• A ternary has to produce value - so a ternary expression will always have to have two possible outcomes (values). (BTW - what else returns a value: a function).

If you have an imperative programming style you will be thinking and programming in statements. As such you will default to if statements (me - programming C decades ago and going "yech" every-time I came across a ternary).

Once you start using a functional language (say Erlang, OCaml, Haskell, Elixir, Clojure, etc.) statements go out the window (even Rust, though imperative, is largely expression-based). You have to deal with everything in terms of expressions producing values (not statements mutating values; PLOP - Place-Oriented Programming) because expressions - just like functions - take some values as inputs and produce a new value. There is no if statement - only conditional expressions.

Scheme is in JavaScript's history which is evidenced by its function-oriented nature so while it isn't possible to dump statements entirely (they have their uses 😏) one can develop a more expression-based style - and using ternaries (with tuples and destructuring assignments) is a big part of that.

// ...

function categorize(ch) {
  return 'a' <= ch && ch <= 'z'
    ? CHAR_CATEGORY.LowerCase
    : 'A' <= ch && ch <= 'Z'
    ? CHAR_CATEGORY.UpperCase
    : SEPARATORS.includes(ch)
    ? CHAR_CATEGORY.Delimiter
    : CHAR_CATEGORY.Other;
}

const isAlphabetic = (c) =>
  c === CHAR_CATEGORY.LowerCase || c === CHAR_CATEGORY.UpperCase;

function reducer([last, acronym], ch) {
  const current = categorize(ch);
  return (last === CHAR_CATEGORY.LowerCase &&
    current === CHAR_CATEGORY.UpperCase) ||
    (last === CHAR_CATEGORY.Delimiter && isAlphabetic(current))
    ? [current, acronym + ch.toUpperCase()]
    : [current, acronym];
}

// beginning of phrase is equivalent to a "delimiter"
const INIT_COLLECT = Object.freeze([CHAR_CATEGORY.Delimiter, '']);

function acronym(phrase) {
  const [_last, result] = phrase.split('').reduce(reducer, INIT_COLLECT);
  return result;
}

I always appreciate clear examples about code concepts. The way you wrote this is very similar to how I learned and refactored my code to include ternaries. I also took similar steps to take complex ternaries to revert them back into if/else blocks (not everything needs to be a one-liner 😂)
I'd love to see your thoughts and approach to refactoring vanilla JavaScript to be more es6 compatible, like the different ways there are now to make a function! 🦄

Great Post thank you.