DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป is a community of 966,904 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Tauan Tathiell
Tauan Tathiell

Posted on

Replace your switch statement and multiple "if and else", using Object Literals - [en-US].

Alt Text

So First, What is Switch Statement?

A switch is a function that receives data, and that data will be analyzed, if this data is equal to one of our cases, it makes the instructions in that case and returns a value.

function UserPolicy(type) {
  switch(type) {
    case 'admin':
      return 'This User is Admin!'
      break
    case 'client':
      return 'This User is Client!'
      break
    case 'salesman':
      return 'This User is Salesman!'
      break
    default:
      return 'Ops, this guy doesn\'t have user profile'
  }
}

UserPolicy() // 'Ops, this guy doesn't have user profile'
UserPolicy('admin') // "This User is Admin!"
Enter fullscreen mode Exit fullscreen mode

Itโ€™s similar to if and else statements, but it should evaluate a single value โ€“ inside the switch we use a case to evaluate against each value.

When you are using lots of else if statements, something very wrong and generally you should use something like a switch as itโ€™s more suited for the purpose and intention. Hereโ€™s some else if abuse:

function UserPolicy(type) {
  let userType
  if (type === 'admin') {
    userType = 'This User is Admin!'
  } else if (type === 'client') {
    userType = 'This User is Client!'
  } else if (type === 'salesman') {
    userType = 'This User is Salesman!'
  } else {
    userType = 'Ops, this guy doesn\'t have user profile'
  }

  return `User is type: ${userType}`
}
Enter fullscreen mode Exit fullscreen mode

Problems with switch

There are multiple issues with switch, from its procedural control flow to the non-standard-looking way it handles code blocks, the rest of JavaScript uses curly braces yet switch does not. Syntactically, it's not one of JavaScript's best, nor is its design. We're forced to manually add break; statements within each case, which can lead to difficult debugging and nested errors further down the case should we forget! We have to treat this with caution.

We often use Object lookups for things in JavaScript, often for things, we would never contemplate using switch for - so why not use an Object literal to replace the switch? Objects are much more flexible, have better readability and maintainability and we don't need to manually break; each case. Theyยดre a lot friendlier on new JavaScript developers as well, as theyยดre standard Objects.

Reasons not to use switch

  • As the number of โ€œcasesโ€ increases, the performance of the object (hash table) gets better than the average cost of the switch (the order of the matter of the case). The object approach is a hash table lookup, and the switch has to evaluate each case until it hits a match and a break.

  • More maintainable and readable. We also donโ€™t have to worry about break; statements and cases falling through โ€“ itโ€™s just a plain Object.

Normally, we would put a switch inside a function and get a return value. Let's do the same here and make the switch case a usable function with a return of an Object Literal:

function UserPolicy(type) {
  // We create a const that receives an object and each of its properties.
  // will be the values corresponding to our types
  const Users = {
    admin: 'This User is Admin!',
    client: 'This User is Client!',
    salesman: 'This User is Salesman!',
    default: 'Ops, this guy doesn\'t have user profile'
  }

  return Users[type] || Users.default
}

UserPolicy() // 'Ops, this guy doesn't have user profile'
UserPolicy('admin') // "This User is Admin!"
Enter fullscreen mode Exit fullscreen mode

Overview

Object literals are a more natural control of flow in JavaScript, the switch is a bit old and clunky and prone to difficult debugging errors. Objects are more extensible, maintainable, and we can test them a lot better. Theyโ€™re also part of a design pattern and very commonly used day to day in other programming tasks. Object literals can contain functions as well as any other Object type, which makes them really flexible! Each function in the literal has function scope too, so we can return the closure from the parent function.

//I'm not dictating the rule - it's just another way of solving our everyday problems

Top comments (27)

Collapse
 
kibobishtrudelz profile image
Petar Kolev

From syntactic point of view ternary is way more terrible to read instead of switch :d

Collapse
 
deathshadow60 profile image
deathshadow60

Most of your arguments against SWITCH are in fact it's features. It's like the derpy linters that throw a hissy-fit if you drop-through, one of the entire reasons to use switch in the first place. Oh noes, you have to say break, return, or continue, notz thatz. :/

Though I'm often dismayed how often I see break; after a return; (hurr-durrz) or how many people don't realize continue can also be used there.

From an efficiency standpoint, your claims of disadvantages of switch are more myth than fact. JavaScript table lookups are still going to do comparisons, you are manually coding such a comparison so if anything is going to be slower in execution, it's probably your (Users[type] || Users.default) given how piss poor the performance of JS object indexes are. JUST like the painfully bad performance of JS' ALLEGED arrays. (that are in fact pointered lists).

That said, it's often better to use the object approach you mention for code clarity or organization sake, it's an obvious answer in a lot of situations, but comparing it to IF or SWITCH? Yeah, no.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

Thanks for ur review.. i wrote this article to pass, what i'm leraning .. how i said "//I'm not dictating the rule - it's just another way of solving our everyday problems" ... i don't have 40 years in programming .. u have more arguments then me , i know it .. i was trying to share something cool .. that i learned .. i'm sorry about that :D

Collapse
 
seanmclem profile image
Seanmclem

I like your approach better, and agree with your logic for using it. keep it up

Thread Thread
 
lukyhenson profile image
Tauan Tathiell Author

Thanks man ... let's keep sharing knowledge...

Collapse
 
nikitahl profile image
Nikita Hlopov

Nice article and interesting approach. Thanks!
I have a question however. Why would you use methods to return the string instead of assigning this string to a property like so:

const Users = {
  admin: 'This User is Admin!',
  client: 'This User is Client!',
  salesman: 'This User is Salesman!',
  default: 'This User is MasterUser'
}

I mean wouldn't it be more clean and straightforward way?

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

Hey man ... thanks .. so in the project that i'm current working i used methods to change the data and other things ... it was just a mistake hehehe i'm sorry .. your approach is absolutelly correct... thanks for your review i'm going to edit it ..

Collapse
 
akolybelnikov profile image
Andrey Kolybelnikov

I was about to comment with the same when I saw this has already been suggested :)
One more cool little enhancement will allow you to adhere to immutability principle (that is if you'd like to prevent anyone from changing your object properties somewhere in the code later):

Object.freeze(Users)

From now on your object literal is readonly.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

hey man thanks for the comment :D

Collapse
 
dance2die profile image
Sung M. Kim

Thanks for sharing the post in both English & Brazilian Portuguese (pr-BR).

For those who want to read pr-BR version, check out this post.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author • Edited on

Thanks man... I'm going to do that for all my articles .. i'm trying to share to our community, everything i'm learning :D

Collapse
 
dance2die profile image
Sung M. Kim

You're welcome and I appreciate sharing your knowledge/experience :)

 
lukyhenson profile image
Tauan Tathiell Author

Thanks man .. i liked a lot your approach...
// I'm not dictating the rule - it's just another way of solving our everyday problems. hehehehe

 
kibobishtrudelz profile image
Petar Kolev

Yes, I do because in my workโ€™s project we have many ternary operators used and when they are long itโ€™s brain damaging while reading them. Again - just from synthetic point of view :)

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

thanks for ur review, i put this default user just to show a sample how to use. but i understand ur point .. i'll change some code's soon... one more time Thanks xD

Collapse
 
juancarlospaco profile image
Juan Carlos

I think this should be benchmarked to prove that this construct is better than the switch,
my guess is it is not.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author • Edited on

I take this printscreen by benchmark test ...

altimage

Collapse
 
obsessiveprogrammer profile image
Tom Bonanno

Very cool. Thanks for sharing. One issue I can see that you should be aware of is that you won't get an accurate code coverage result for testing, as it will not be seen as branches.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

Thanks for your review man .. i'll update this article or create another to update with new things

Collapse
 
kibobishtrudelz profile image
Petar Kolev

This will be pretty neat if you have super long switch in React reducer for instance =] Thanks for the article! Itโ€™s nice to know another way of doing things!

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

Yes man .. i like this approach .. i dont guess this will solve all my problems but is a cool approach... thanks for your review

Collapse
 
kulpras profile image
Prasanna Kulkarni

I liked the way you explained. Will use object literals in my future projects.

Collapse
 
lukyhenson profile image
Tauan Tathiell Author

Hey man appreciate that.. thanks a lot

๐ŸŒš Friends don't let friends browse without dark mode.

Sorry, it's true.