to-switch-or-not-to-switch.md

To Switch or Not to Switch

You know, before Redux came out I had this idea in my head that the switch statement wasn't great. I don't think I was alone in thinking that either. I was under the impression that it was "preferred" or "best practice" to use object literals instead. For whatever reason, Redux seems to have repopularized switch for better or worse.

Old habits die hard. While reading through the tire icon util, I couldn't help but think all these switch statements could be replaced by simple object literals.

You can completely forget what you've read above, and ignore what's written below. But, in case you're curious here's how those switch statements can be refactored into maps:

getNumForLetter using switch (Current):

const getNumForLetter = (letter: string) => {
  switch (letter) {
  case 'V':
  case 'Z':
    return 240;
  case 'W':
    return 270;
  case 'Y':
    return 300;
  default:
    return 0;
  }
};

getNumForLetter using an object literal (Future?):

const getNumForLetter = (letter: string) => ({
  V: 240,
  Z: 240,
  W: 270,
  Y: 300
}[letter] || 0);

mapClassificationToIcon using a switch (Current):

export const mapClassificationToIcon = (cls: string): any => {
  switch (cls) {
  case 'Raised White Letter':
    return {src: iconWhiteLetter};
  case 'White Sidewall':
  case 'White Sidewall - White Wall':
  case 'Extra Narrow White Stripe':
    return {src: iconWhiteWalled};
  case 'White stripe':
  case 'Outlined White Letter':
    return {src: iconWhiteOutlined};
  case 'Red letters':
    return {src: iconRedOutlined};
  default:
    return undefined;
  }
};

mapClassificationIcon using an object literal (Future?):

export const mapClassificationToIcon = (cls: string): any => ({
  'Raised White Letter': iconWhiteLetter,
  'White Sidewall': iconWhiteWalled,
  'White Sidewall - White Wall': iconWhiteWalled,
  'Extra Narrow White Stripe': iconWhiteWalled,
  'White stripe': iconWhiteOutlined,
  'Outlined White Letter': iconWhiteOutlined,
  'Red letters': iconRedOutlined,
}[cls]);

getRawIcon using switch (Current):

export const getRawIcon = (type: string, code: string): any => {
  let icon;
  switch (type) {
  case 'sidewall':
    icon = mapClassificationToIcon(code);
    break;
  case 'speedrating':
    icon = mapSpeedRatingToIcon(code);
    break;
  case 'runflat':
    icon = mapRunflatToIcon(code);
    break;
  default:
    icon = mapClassificationToIcon(code);
  }
  return icon;
};

getRawIcon using an object literal (Future?):

export const getRawIcon = (type: string, code: string): any => ({
  sidewall: mapClassificationToIcon,
  speedrating: mapSpeedRatingToIcon,
  runflat: mapRunflatToIcon,
}[type](icon) || mapClassificationToIcon(icon));

Here's some further reading on switch from JavaScript (The Bad Parts):

switch Fall Through

The switch statement was modeled after the FORTRAN IV computed go to statement. Each case falls through into the next case unless you explicitly disrupt the flow.

Someone wrote to me once suggesting that JSLint should give a warning when a case falls through into another case. He pointed out that this is a very common source of errors, and it is a difficult error to see in the code. I answered that that was all true, but that the benefit of compactness obtained by falling through more than compensated for the chance of error.

The next day, he reported that there was an error in JSLint. It was misidentifying an error. I investigated, and it turned out that I had a case that was falling through. In that moment, I achieved enlightenment. I no longer use intentional fall throughs. That discipline makes it much easier to find the unintentional fall throughs.

The worst features of a language aren't the features that are obviously dangerous or useless. Those are easily avoided. The worst features are the attractive nuisances, the features that are both useful and dangerous.

(Source) http://archive.oreilly.com/pub/a/javascript/excerpts/javascript-good-parts/bad-parts.html

---