Personally, my favorite way to do JavaScript switches is to isolate them to their own function. If you're doing a simple dispatch, a function is already an appropriate abstraction, and return gives you the ability to avoid the break mess.

// Object literal
function createContent(contentType){
   const contentTypes = {
     post: Post,
     video: Video,
     default: Unknown
   };
   const createType = contentTypes[contentType] || contentTypes['default'];
   return createType(); // or new createType() if its a class constructor
}

// Switch
function createContent(contentType){
  switch(contentType){
    case "post": return Post() // or new Post() if its a class constructor
    case "video": return Video()
    default: return Unknown()
  }
}

Utilizing the switch statement also dodges the biggest drawback of the object literal: the location of the object. If you put the object literal in your dispatch function, you're creating the object every time you run the function. If you create the object once outside of the function, now your dispatch logic is in a different place than the actual dispatch call.

I wish JavaScript had a built in pattern matching construct, but a well used switch statement isn't all that bad.

As a personal preference I just try to avoid nesting in any form as much as possible because it really obscures the logic.

Say, this code snippet,

let result = null;
if (conditionA) {
  if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }
} else {
  result = "Not A";
}

into:

function getResult() {
  if (!conditionA) {
    return 'Not A';
  }
  if (conditionB) {
    return 'A & B';
  }
  return 'A';
}

or even:

function getResult() {
  if (!conditionA) {
    return 'Not A';
  }
  return conditionB ? 'A & B' : 'A';
}

Everything else looks fine but the nested turn ops.. not for me, clarity can go a long way over terse for the sake of others. Besides there are alternatives to nested conditionals. Boolean array .every or .some spring to mind.

// similar to x && y
const criteria = [
   user === 'logged-in',
   hasCardDetails
]
if ( criteria.every(isTrue => isTrue) ) {
   // do a thing if all are true
}

// similar to x || y
const criteria = [
   user === 'logged-in',
   hasCardDetails
]
if ( criteria.some(isTrue => isTrue) ) {
   // do a thing if some are true
}

3. One loop two arrays

Is reduce really necessary here? Wouldn't it be so much clearer to do this with a forEach?

const exampleValues = [2, 15, 8, 23, 1, 32];
const truthyValues = [];
const falseyValues = [];
exampleValues.forEach(exampleValue => {
        if (exampleValue > 10) {
            truthyValues.push(exampleValue);
        } else {
            falseyValues.push(exampleValue);
        }
});

5. Nested ternaries

The same flow you used in the ternaries can be applied to the if statements:

let result = null;
if (!conditionA) {
    result = "Not A";
} else if (conditionB) {
    result = "A & B";
} else {
    result = "A";
}

And if you used the same flow as in your if statements but with ternaries, they'd also look weird:

const result = conditionA
    : (
        conditionB
        : "A & B"
        ? "A"
    )
    ? "Not A";

Also, I find ternaries formatting to be more readable this way:

const result =
    !conditionA ? "Not A"
    : conditionB ? "A & B"
    : "A";

Personally, I don't like the nested ternary conditions.

const result = !conditionA
  ? "Not A"
  : conditionB
  ? "A & B"
  : "A";

Instead of the nested if..else, I would prefer the "Early assignment" like "Early Exits"

let result = null;
if (conditionA) {
  if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }
} else {
  result = "Not A";
}

// instead

let result = "";

if(!conditionA) result = "Not A";
if(!conditionB) result = "A"
result = "A & B"

Nice post!

Re #1: Rubocop calls them "guard clauses" and I tend to prefer that style as well.

But if there are only two branches, I sometimes prefer the symmetry of if / else. Especially when if is an expression (as it is in Ruby).

Either way, IMO it's usually clear enough when input validation is being done, however it gets written. It's one of those places where obscuring the intent takes real talent :P

Re: #2: agree with @nepeckman that putting the switch statement in a function is usually a good option. Especially if multiple cases map to the same output value, because there you can use switch fallthrough to "stack" the tests and avoid repeating yourself.

Re: #3: reduce (fold) is so powerful 😍... map and filter can both be written in terms of it, and many more things as well. Many "indexed" loops can be translated into a function folded over a range of integers.

Also, I haven't seen it formalized, but it seems like a lot of tail-recursive code can be translated to "reducer style" as well -- it's a good option if the inputs can be easily generated as some sort of collection.

If the fold implementation allows early termination (a la Clojure's reduced, it becomes even more useful.

Part of our coding standard is no acronyms (with a very few specific exceptions for industry terms). It is amazing how much easier it is to read code from 5+ years ago when it isn't littered with little three letter shibboleths.

I think nesting ternaries makes things more difficult to change later without scratching your head. The linked article says it simplifies the conventional if

const withIf = ({
  conditionA, conditionB
}) => {
  if (!conditionA) return valueC;
  if (conditionB) {
    return valueA;
  }
  return valueB;
};

but it doesn't go all the way:

const withIf = ({
  conditionA, conditionB
}) => {
  if (!conditionA) return valueC;
  if (!conditionB) return valueB;
  return valueA;
};

At this point the if and the ternary are nearly identical, with the exception that the if statement blocks can contain anything they like without breaking the layout. Imagine if instead of returning a simple value they were all returning a long string or a calculation? I mean, you can say that these sorts of things should be factored into their own functions, but that's true of both techniques.

Early exits keep indentation sane which contributes a lot to readability.

Nested ternaries are great and very clear if you lay them out like:

const result =
  !conditionA ? "Not A" :
  conditionB ? "A & B" :
  "A";

so the structure of each line is exactly the same.
(Don't try this in PHP by the way - you need parens to fix the broken associativity).

You're right. I have found it is exactly easy to understand the ternaries because the priority level is default satisfying what I want it to be. But One loop two arrays I don't agree. I code the following code and it is more elegant:

const validTrolley = result.filter(item => item.inventoryCount && item.putShelvesFlg)
const invalidTrolley = result.filter(item => !(item.inventoryCount && item.putShelvesFlg)).map((item, index) => {
            item.isInvalid = !index;
            return item;
          })