[QUESTION] Why do we need both `useBooleanState` and `useToggle `?

[ho991217]

Describe the issue

While I skimming through your document, I noticed that there are useBooleanState and useToggle . I wonder if both of these hooks are needed. I think that they are virtually the same. In specific, isn't useToggle subset of useBooleanState?

Additional context

N/A

[seungrodotlee]

From a functional perspective, useToggle can be seen as a subset of useBooleanState.
However, I believe they are quite different in terms of interface.

While useBooleanState does include a toggle method, in most cases, it's used when you explicitly want to set the value to true or false using setTrue and setFalse.

In contrast, useToggle is purely focused on providing a toggle behavior — it’s simple, direct, and purpose-driven.

I believe the two hooks are clearly distinct, and the difference in their interfaces is meaningful and worth preserving.

// usage of useBooleanState
const [staste, setTure, setFalse] = useBooleanState();

// usage of useToggle
const [state, toggle] = useBooleanState();
// it's better than
// const [state, , , toggle] useBooleanState();

[ho991217]

In terms of manipulating Boolean value, I think preserving both hooks may cause confusion rather than making usage clear.
In respect of "simple, direct, and purpose-driven.", then I wonder if removing toggle interface from useBooleanState makes sense in that regards.

[manudeli]

I want to make BREAKING CHANGE for this useBooleanState because of this ( toss/slash#203 (comment) )
(I'm toss member, but I'm not maintainer of react-simplikit. so I have no right to make it)

Since react-simplikit is still in version 0, I hope you consider BREAKING CHANGE quickly.

[seungrodotlee]

Regarding the interface change for useBooleanState, we think it requires some careful consideration.

We saw two suggestions: one was to remove toggle from useBooleanState, and the other was to provide the setters as an object—allowing usage like setter.toTrue, setter.toFalse, and setter.toggle.

Here’s a breakdown of the pros and cons of each approach:

• Current approach: Similar to React’s interface. Useful when setTrue or setFalse is used together with toggle for the same state. However, when that's not the case, toggle may become an unnecessary part of the interface and can conflict with the role of useToggle.
• Removing toggle: Also similar to React’s interface. Might be inconvenient in scenarios where setTrue, setFalse, and toggle are frequently used together.
• Providing a setter object: Useful when only setFalse or a combination of setFalse and toggle is used, without setTrue. However, this diverges most from React’s interface and may feel unfamiliar.

To make an objective decision, we reviewed 321 usage cases of useBooleanState with the current interface in our internal codebase, and found the following distribution:

Total usages: 321

• [setTrue]: 86

• [ , setFalse]: 20

• [ , , toggle]: 25

• [setTrue, setFalse]: 182

• [setTrue, , toggle]: 1

• [ , setFalse, toggle]: 5

• [setTrue, setFalse, toggle]: 2

• Cases using setTrue or setFalse together with toggle: 8 (2.5%)

• Cases using only setTrue or setFalse: 288 (89.7%)

• Cases skipping unnecessary elements in destructuring, excluding toggle-only usage: 6 (1.9%)

Based on this data, removing toggle seems to be the most reasonable approach.

We’ve decided to proceed with removing toggle, and I’ll submit a PR reflecting this change sometime this week.

[ojj1123]

Based on this data, removing toggle seems to be the most reasonable approach.

It sounds reasonable!

But I'm wondering if it's good to provide both of array and object return types from useBooleanState. Actually I opened a discussion last week. Does it make users confused?

const [state, setTrue, setFalse, toggle] = useBooleanState()

// and also it's possible

const { state, setTrue, setFalse, toggle } = useBooleanState()

[seungrodotlee]

In my opinion, providing only a tuple-style return value would be clearer.

While offering multiple options could be seen as a way to satisfy diverse needs, but I believe that sticking to a tuple return value would offer the most consistent experience with React's interface. Also, based on the data, the proportion of cases that actually required an object-style return value didn’t seem to be that high.

[jungpaeng]

I believe there is no need to provide both useBooleanState and useToggle. Offering just one of them would be more user-friendly.

Having too many features in a library might increase flexibility, but it can also cause unnecessary confusion for users.
Although it was mentioned that the purposes of useToggle and useBooleanState are clearly different, their functionalities are very similar, and I don’t think most users will distinguish between them clearly in practice.

I would also like to comment on the interface of the useBooleanState hook.
Currently, it provides multiple setters in a tuple format. It was mentioned that this approach is more "React-like" because it’s similar to React’s useState API.

However, I don’t agree with that reasoning.
React’s useState uses a tuple because it only needs to return two values: a getter and a setter. Returning [getter, setter] is a pattern commonly seen in other libraries as well.

But useBooleanState is different.
It doesn’t return a single setter — it returns multiple setters.

Although the internal codebase analysis showed that skipping values in destructuring is rare, that’s just an internal usage pattern. This library is no longer just for internal use — it should offer a more extensible and user-friendly interface. I believe the best way to achieve that is by returning the setters as an object.

If the goal is to provide an interface consistent with the "React experience", then it would make more sense to remove useBooleanState entirely and just keep useToggle.

Other popular hook libraries have already taken this approach:

• https://github.com/streamich/react-use/blob/master/docs/useToggle.md
• https://usehooks.com/usetoggle

Therefore, instead of simply removing toggle from useBooleanState, I propose removing useBooleanState altogether and keeping only useToggle.

[seungrodotlee]

I still believe that having both useBooleanState and useToggle coexist is the more appropriate direction.

It's true that the usage analysis of useBooleanState was based only on internal code, but I don’t think the results would change significantly in external environments.

The data was collected across various repositories, teams, and projects,

And in nearly 90% of cases, only setTrue or setFalse were used — the result is clear enough to suggest that there’s little ambiguity in how the hook is used.

This strongly supports the idea that offering a tuple-style interface — even without toggle being destructured in most cases — remains an intuitive and efficient approach in real-world usage.

Although it's valid to say that useBooleanState and useToggle are functionally similar, that alone doesn’t justify the removal of one. In the React ecosystem, many hooks with overlapping purposes coexist, each serving different use cases. I believe this kind of coexistence is not about redundancy, but about providing developers with meaningful options that help them express intent more clearly.

useToggle is optimized for simple boolean toggling logic, whereas useBooleanState — by offering setTrue, setFalse — allows for more declarative and explicit control of boolean state.

I also don’t fully agree with the argument that useBooleanState should return an object instead of a tuple, simply because it includes multiple setters.

In 83% of usage cases, either only setTrue or both setTrue and setFalse were used — this means the majority of developers are already using the setters in the exact order returned by the tuple.

The tuple-based interface provides flexibility and naming freedom, allowing developers to pick what they need. This makes destructuring not only simpler than using an object, but also more intuitive and concise in actual coding practice.

Both hooks are actively used, and allowing developers to choose between them based on their needs improves the clarity and scalability of the library. To reduce potential confusion, the better solution isn’t removing functionality — it’s to provide clearer documentation and guidance.

Therefore, instead of removing useBooleanState, I believe a more user-friendly approach is to let both hooks coexist while clearly communicating their distinct use cases.

[jungpaeng]

The fact that only setTrue or setFalse was used often implies that the initial value was set to either true or false, and then the value was flipped.

In essence, I believe this behavior closely resembles what toggle is meant to do. In fact, even though the toggle() function is not explicitly used in many cases in the internal codebase, setTrue or setFalse are often being used as if they were toggling the state.

Given this, I don’t think it’s a good idea to evaluate usage patterns purely based on numerical data. It doesn’t always capture the underlying intent or semantics of the code.

That said, I do agree with the idea that useBooleanState and useToggle have different goals, and offering both provides developers with clearer, more expressive choices. However, considering that there are many internal cases where toggle-like behavior is implemented without using the actual toggle function, I’m not fully convinced that this distinction will be effectively reflected in practice.

Personally, I believe it’s ideal for a library to provide only one clear way to achieve a specific goal. But that’s just my opinion, and I respect the decision to provide both useBooleanState and useToggle.

Thank you.

[jsleemaster]

First of all, I respect the main maintainer’s opinion, but referring to this comment (https://github.com/toss/slash/pull/203#issuecomment-1407760618), I believe this tuple-style interface results in unnecessary code. And according to the earlier comment, wasn’t there a discussion that Toss would prefer the [getter, setter] interface to return an object? Below is the code.

function Example() {
  const [isFlag, flag] = useIs()

  return (
    <>
      <button onClick={flag.toTrue}>turn on</button>
      <button onClick={flag.toFalse}>turn off</button>
      <button onClick={flag.toggle}>toggle</button>
      {isFlag ? 'true' : 'false'}
    </>
  )
}

Also,

Total usages: 321

• [setTrue]: 86
• [ , setFalse]: 20
• [ , , toggle]: 25
• [setTrue, setFalse]: 182
• [setTrue, , toggle]: 1
• [ , setFalse, toggle]: 5
• [setTrue, setFalse, toggle]: 2
• Cases using setTrue or setFalse together with toggle: 8 (2.5%)
• Cases using only setTrue or setFalse: 288 (89.7%)
• Cases skipping unnecessary elements in destructuring, excluding toggle-only usage: 6 (1.9%)

And I’m finding these usage stats confusing. Isn’t it possible that users chose other solutions in the cases where usage was low?