DEV Community

loading...
Cover image for Car keys toggle it right !

Car keys toggle it right !

dmail profile image Damien Maillard ・2 min read

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
}
Enter fullscreen mode Exit fullscreen mode

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
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Discussion (5)

pic
Editor guide
Collapse
jayjeckel profile image
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.

Collapse
dmail profile image
Damien Maillard Author

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.

Collapse
jayjeckel profile image
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.

Collapse
hamza_ataboh_429e1c9b9fa3 profile image
Hamza Ataboh

She’s a keeper.

Collapse
alaindet profile image
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.