Car keys toggle it right !

Sometimes I feel that a way of doing things is better than another but I struggle to explain why. For example, I don't like when a function, especially a public api, uses "toggle" behaviour.

To illustrate, let's make a public api controlling if volume is muted or not.

let muted = false

export const mute = () => {
  muted = true
}

export const unmute = () => {
  muted = false
}

In the past, I got tempted to merge mute and unmute into a "smart" toggle function

let muted = false

export const toggleMute = () => {
  if (muted) {
    muted = false
  }
  else {
    muted = true
  }
}

Only to realize that first version was better. But I was struggling to explain why to other developers. And that lasted for long. From time to time, I was wondering what could be the "perfect" example to illustrate my feelings.

Until one day.

We where walking in the city with my girlfriend, which is also a dev.

Me: Do you remember when I told you I don't like when api uses toggle?
Her: I do, yes
Me: I was thinking again how to illustrate that... I like when one button do one thing. Toggle is not user friendly but I still can't explain why with a simple example.
Her: Thinks... Got it! It's like when you want to lock your car... You don't want to know if your car is locked before pressing the button. You just want to lock your car by pressing a button. Maybe it was useless because the car was already locked but that's not what matters for you. With a toggle you would have to remember if the car is locked otherwise you could unlock it by mistake and have to lock it back.

I don't know if that rings a bell for you, but for me it illustrates simply why I prefer having 2 buttons:

• one to lock the car
• an other to unlock the car

Applied to a car, we don't want a toggle because user would have to keep in memory the state of the car.
Applied to a program, we don't want a toggle function because code outside have to remember the state as well.

Comments

[Jay Jeckel]

Agreed about the locking of cars not being a toggle, but mute is a toggle.

You aren't going to have two buttons on a music player, one to mute and one to unmute, you're going to have one button that toggles the mute state. As for the API, you should have all three methods (mute, unmute, and toggleMute) and let the API consumer decide if and how they wish to use them.

[Damien Maillard]

I see, but for me toggle does not translates the user intent correctly.

I think a user would phrase his intent like this:
"I want to mute" or "I want to unmute". Not "I want to toggle mute"

Once you need to describe user action in an object (for redux, tracking, whatever) it becomes clear for me: I would not describe the action using "toggle mute" because it is dependent of the state, it does not translates the intent correctly. I would rather use "mute" or "unmute" to clearly describes what user wanted at that point.

I think exposing a toggleMute function is exposing a way to misinterpret the caller intent.

[Jay Jeckel]

Sure, but when you get down to actually designing the GUI, the mute/unmute control is going to be a single button. When that button is clicked it is going to toggle the state. Even if your library doesn't provide a toggleMute method, that is the logic that will be used in the button click handler.

Again, I agree with your overall point, not every boolean state semantically represents a toggle, but mute as it is used does represent a togglable state.

[Alain D'Ettorre]

I never use toggle unless I'm sure it's needed because of this. It's an action based on state, which is bad.