DEV Community

Why I prefer objects over switch statements

Enmanuel Durán on February 17, 2019

Recently (or not so recently, depending on when you read this article), I was having a debate with some teammates about how to handle conditions ...

Read full post

David Chase • Feb 18 '19

good article, ive been doing similar recently but i used es6 Maps and dynamic keys

const fn = n => new Map([
  [n < 2, 'Less than 2'],
  [n === 3, 'Equals 3'],
  ['_', 'Some default value here']
])

i use _ as a default value and a little helper like

const cata = map => map.has(true) ? map.get(true) : map.get('_')
cata(fn(3)) // Equals 3

Massimo Artizzu • Feb 18 '19

Nice.
On the down side, you have to be careful that no more than one condition is verified.
On the plus side, '_' looks like a confused face 😐😀

Anyway, you can do that with objects, too, but booleans would get converted into strings.

David Chase • Feb 18 '19

haha just setup a quick example :)

Harry Dennen • Feb 18 '19

Is there a specific benefit of this functional approach? Seems to accomplish the same thing but it took me longer to work out what it was doing.

Thomas Junkツ • Feb 18 '19

I though the same: Clever but without practical use.
Reading the code fluently comes here to an unnecessary halt.
map.has(true) ? map.get(true) : map.get('_') Reading this in a codebase makes me go WTF?!.

David Chase • Feb 18 '19

it depends on the codebase, again it was a quick example to showcase another alternative way :)

Olivier “Ölbaum” Scherler • Feb 17 '19

I agree that when a switch statement is used to perform a mapping (which is not always the case), then it’s usually better to replace it with an actual mapping. But we should also keep readability in mind. Your last switch statement immediately shows what it’s doing. The object approach is less immediate.

(Also, pattern matching is not an ES6 proposal, it’s an ancestral FP principle that’s proposed for addition to ES6.)

Shreya Dahal • Feb 18 '19 • Edited

I tend to do this in JS as well, but it was more of a habit I carried from Python, which does not have switch..case and the common way to replicate that behavior is to use objects (dicts).

I would put the cases in a closure instead of the function itself to save some memory (granted it's a tiny bit).

const getEditorType = (() => {
    const itsCodeEditor = () => 'It is a code editor';
    const itsIDE = () => 'It is an IDE';

    const editors = {
        atom: itsCodeEditor,
        sublime: itsCodeEditor,
        vscode: itsCodeEditor,
        webstorm: itsIDE,
        pycharm: itsIDE,
        default: () => 'unknown'
    };

    return type => (editors[type] || editors.default)();
})();

Mihail Malo • Feb 18 '19

My favorite is that if the object is in the outer scope, you can statically link to a value instead of having a function call with a hardcoded string argument.
In many cases this enables making definitions not recursive, like the example in my post:

Another GOTO to avoid

Mihail Malostanidis

#practices#refactoring#tips#programming

I just wish other people were more accepting of this approach.
That's not always the case :v

I am glad you mentioned the pattern matching proposal, in my opinion the closest implementation of it in current JS is actually the early return pattern:

const aMatchingFunction = arg => {
  if (typeAssertion(arg)) throw new Error(`Bad types`)

  if (matchPredicate1(arg) return matchBody1(arg)

  if (matchPredicate2(arg) return matchBody2(arg)

  const {param} = arg
  if (param && matchPredicate3(param)) return matchBody3(param)

  throw new Error(`No match, got ${arg}`)
}

It looks imperative at a glance, but with just a little discipline it serves the role very well.

Mikael Klages • Feb 18 '19

It's kind of interesting that the way you use objects here allow you to write code similar to how switch statements work in some languages.

As an added bonus, writing it like this may let you implement a different feature present in some languages, that checks if a switch has covered all possible inputs (usually used with enums). This could prevent stuff like, having one entry misspelled, or somebody adding something somewhere, but not updating all the linked "switch"es.

Though depending on the implementation, this may be even more work or cause more trouble.

Stephen Chiang • Feb 17 '19

I tend to use this method for very predictable objects that otherwise would have been unnecessarily long switch statements. Good stuff

Harry Dennen • Feb 18 '19

I agree with this. Switch statements have a place but more and more my team has been implementing this kind of strategy pattern instead.