DEV Community

Switch is ok

Pragmatic Maciej on May 08, 2020

Switch statement had lately some bad fame, some developers avoid it as possible, and others advocate to deprecate it. Almost as if it would be some...

Read full post

Heiker • May 8 '20

The best thing about switch statements is that you're not limited to strings.

function fun(data) {
  switch(data.constructor) {
    case Symbol:
      return 'You gave me a symbol';
    case String:
      return 'No strings attached';
    case Array:
      return 'To map or not to map';
    case Number:
      return 'something something 42';
    case Boolean:
      return 'is it true?';
    case Promise:
      return 'maybe, maybe not';
    case Function:
      return "Don't call us, we'll call you";
    case (async () => {}).constructor:
      return 'Ooh, fancy stuff';
    default:
      return 'what?'
  }
}

const some_fun = function() {};
const async_fun = async function() {};

fun(['hello']);
fun(74);
fun('this');
fun(Symbol('What?'));
fun(true);
fun(some_fun);
fun(async_fun);

Pragmatic Maciej • May 9 '20

Nice. Thanks for sharing

José Muñoz • May 8 '20

I am in the bandwagon of object literals over switches, I know it doesn't have a tremendous impact but combining it with some ES8 features like optional chaining and nil colascing makes it even better IMO:

const counter = (initialState = 0) => (action) => {
  const nextState = {
    'INCREMENT': () => initialState + 1,
    'DECREMENT': () => initialState -1
  }[action.type]?.() ?? initialState

return nextState
}

Pragmatic Maciej • May 9 '20

It goes to the point that switch is not expression. Don't get we wrong optional chaining and nulish colascing are great feature, but I don't believe using them as you have shown is a good example. It's just not needed here.

José Muñoz • May 9 '20

Hahaha I agree completely, specially nil colascing which would easily be replaced with a logical or instead, it’s just a personal preference

Jon Randy 🎖️ • May 10 '20 • Edited

Your example with the object literal is overly long:

const hero = (x = "default") => ({
    "DC": "Batman",
    "Marvel" : "Wolverine",
    "default": "Spiderman"
}[x])

Pragmatic Maciej • May 10 '20

I have waited for that 😉

Adam Nathaniel Davis • May 9 '20

I've been in both camps before. I think I went at least 10 years without writing a switch/case anywhere. But in the last several years, I've actually come back to switch statements. It's not like I use them everywhere - or even, often. But I do use them. IMHO, the "proper" use-case for switches is whenever you are checking one variable against a set of known values. I do not like any use of a switch where people are trying to embed logic that goes beyond the basic idea of a switch.

Also, although I'm, admittedly, a Certified Redux Hater, it's hard for anyone to love Redux and hate switches. I've even seen Redux fanboys grumble about switches that are written outside of their reducers - but they're perfectly fine using a ton of switches inside their reducers. Such pedantic distinctions make little sense.

Railing against the use of switch makes no more sense than railing against a while loop. Are while loops usually the "right" choice?? No. But there are absolutely times when a while loop is the right choice.

nosknut • Aug 29 '21

Can we all just gather around the campfire and agree that redux is an unmatched headache? 😂 People dump implementation logic of 50 lines in their reducers and the code becomes impossible to follow in large projects.

Sergiy Yevtushenko • May 9 '20 • Edited

New and shiny doesn't mean better.

Smaller doesn't mean better 😂, when you look at both for sure you need a little more time for the second.

I'm constantly telling those phrases to Kotlin fans :)

Torsten Dittmann • May 9 '20

My favourite Javascript switch feature is the ability to use switch(true) followed by cases with with comparison operations.

Looks much cleaner compared to a lot of if/else.

Dan Blaisdell • Jul 19 '22 • Edited

const counter = (state = 0, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1
    case 'DECREMENT':
      return state - 1
    default:
      return state
  }
}

can just be

const increment = (number = 0) => {
  return number + 1
}
const decrement = (number = 0) => {
  return number - 1
}

unless you need it to be so dynamic (uses user input or is an event handler that lacks types) that your code doesn't know which action to take without user input. if you end up writing:

counter(5, 'increment')

...you are just converting function names into string names and making your code breaky and complicated and too clever for its own good

Comment deleted

nosknut • Aug 29 '21

Depends on how extreme it is. If i have to spend an extra 10 seconds reading your code to understand something that a switch could tell me in 2 lines, and i have to do that every time i read your code 20 times a day for a year, we are having a meeting 😂 Otherwise, people can do whatever they want for all i care.

Patrik Jajcay • May 11 '20

Lodash _.cond with lodash/fp version for the win!

Pragmatic Maciej • May 9 '20

Yes you are right, I have wrongly made a title of this paragraph. Changed already

Ryan Dsouza • May 21 '21

+1, although I would love for pattern matching to land in JavaScript as it's the best of both worlds :)

Stevo82930 • Sep 17

I love switch statements because they do the thing I read about all the time: "Make readable code." If readable code is virtuous, then switch should not be deprecated.