<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 "> Bitovi Blog - UX and UI design, JavaScript and Front-end development

Use Objects or Switch Statements in Javascript?

The Bitovi Team

Bitovi's React team discuss object literals and switch statements in Javascript. Learn the pros and cons of each.

posted in JavaScript, React, best practices on January 10, 2022 by The Bitovi Team


Use Objects or Switch Statements in Javascript?

The Bitovi Team by The Bitovi Team

Do you use switch/case statements or do you use object literals in your Javascript? 

Here at Bitovi, our developers know their stuff and enjoy sharing their  (sometimes strong) opinions about why they use what they use.  A few days ago, Bitovi's React team had an impromptu Slack discussion about using switch/case statements or objects in Javascript, along with some thoughts about code performance and a defense of if/else. Check out what our experienced developers have to say.

Switch Statements or Object Literals?

Here's the conversation (complete with emojis):

Cory-Bass Cory Bass 

I came across this article over the weekend, discussing the pros and cons of using objects over switch statements in Javascript. I’d like to hear some thoughts on the pros and cons of each method, if you can find time for it. 

 

 Arar Duqoum  :squirrel:

The argument they put forth on first blush seems to come down to switch not using curly braces and looking a little weird to a JS only developer's eyes. That's a valid point IMO, but the alternative that is put forth is both nonintuitive and kinda strange looking to me. Switch/case statements have always looked all right to me and aren’t in the least cumbersome.

:raised_hands:1

 

 Arar Duqoum :squirrel:  

I think for simple cases where you are not doing significant functionality in the switch/case statements then this approach is cleaner but otherwise I think this is overkill.

 

jane-atherton Jane 

Switch statements are probably implemented O(n) where n is the number of cases -- similar to doing:

if (x || y || z || etc...) 

Object literals are O(1)

:heavy_plus_sign:2

 

 Andrew Coleburn

I like this actually. But I can freely admit that it's because I hate switch/case. I think the argument that switch/case is weird in JS is a valid point against it as well. I've always found them super clunky and annoying/difficult to debug when something goes wrong (which it often does). and I think the approach offered here is pretty straightforward, especially if you're a JS dev who doesn't work in anything else (:man-raising-hand::skin-tone-2:) That said, I don't agree that the chain of if/else  is bad. A bit verbose maybe, but very clear, readable, and easier to debug, IMO. Interesting thought on the performance aspect as well, @Jane...

 

Christopher (he/him) 

I use these constructs all the time, but I conceptualize them differently than switches. I use these for things that clearly fit a “lookup” pattern. Whereas switches are generally for a chained if-else type pattern (in which I actually use a chained if-else because it's clearer and easier to understand). If my cases and breaks don’t line up 1-1 and I need more complex behaviors where a switch would be better, I’ll generally make a new function where I have full compel over early returns. TBH, I don’t like or use switches. ¯\_(ツ)_/¯

:raised_hands:2

 

 Arar Duqoum :squirrel:  

I think the performance argument is ok as far as it goes. It's not wrong. But big o runtime analysis for small numbers doesn't really hold sway since at low numbers you can't disregard constants and implementation details. So it's correct but I personally wouldn't accept it as a cornerstone for a decision to use this style over case switch.

 

Mark Thompson :moocow:

I like if/else since everyone knows how they work and they’re much more common than switch/case. Usually if the list gets long, it’s unlikely that I care about how many more lines if/else takes since I end up adding comments to clarify what’s going on on each style anyway.For more complex stuff, I move things into functions. This helps unit tests and makes your code compact~I like to use object literals for when there’s like 10+ cases and moving logic to a separate function doesn’t help.

Either way, switch/case is cool (I just treat them like if/else). And object literals are cool as long they’re commented since they tend reserve them for the messy stuff.

-In the article:
The first getDrink example shouldn’t use shadow reference of “type” wuhahahaha. But makes sense to me to instinctively move to switch/case or an object literal given the example looks like a look up pattern. I’d go as far to say use an enum for everything that’s not the default case, then wrap in a function to provide the default case.

// The drink I chose was Coke
console.log(drink);

I also drink Coke when I’m reaching for a soda

function getDrink (type) {
  return 'The drink I chose was ' + {
    'coke': 'Coke',
    'pepsi': 'Pepsi',
    'lemonade': 'Lemonade'
  }[type];
}

I personally don’t like this type of stuff since it’s not saving many more lines and the code is becoming more complex than it needs to be. An obvious error in this case would be that you’re passing an “invalid” type such as “sprite”, but that’d take a few moments to realize when debugging “Object literal’s function”. Without something like typescript, doing stuff like this will always force people to look up how your code works since it’s not common, I’d avoid this if you don’t have types.

-Overall, all of these styles are valid to me. Some are little too ninja  for my taste, but cool stuff~ 

:raised_hands::skin-tone-2:2

 

So what do you think? Leave us a comment below and let us know what you use and why.

We're Hiring

Would you like to be part of our React team? 

Bitovi is a group of really talented software engineers and product designers.  We're a fully remote team. We only hire the best and we're always looking for top-notch people to grow our team. If you think you have what it takes, view our openings.

Create better web applications. We’ll help. Let’s work together.