A new Checkbox component

[arHSM]

• I'd like to suggest a checkbox message component...

How does it benefit bots?
Certain bots require certain settings to be configured. Some bots allow the user to change/toggle these settings by commands but adding a checkbox component will make it easier for the user to toggle these settings.
Other than the use for toggling settings it can be used for many functionality in bots i.e. polls/votes, lists, etc... there are several use cases for a checkbox component.

Possible features that could use checkboxes :

• TODO lists
• Bot settings such as disabling and enabling certain features of the bot since most bots don't have a dashboard and integrating their settings in the Discord UI makes it look clean all across the platform and might introduce a user friendly bot configuration system for newcomers.
• Polls/Votes like a user can interact with a button and then a ephemeral message can contain these checkboxes with options, which is really helpful during quizzes.
• ModMail bots can introduce a category system to set a "importance" threshold so that community moderators can focus on important events first.
• Private bots creators can create a system for themselves to easily execute fixed commands such as locking/unlocking a particular channel...

[Chiggy-Playz]

I think this could be a possibility in the upcoming forms component.

[ckohen]

Checkboxes would be really nice! I had thought about suggesting this a few times but never did so for a few reasons. Here are a couple of considerations to have though.

• Are checkboxes per user or is state synced across all users
  • If its per user, can state be stored? Select menus already struggle from this and I think Discord would be unlikely to implement state storage if its user side
• Much of the functionality, if not all, of a checkbox can already be achieved using a button and editing that button when pressed (which is how synced checkboxes would have to work, as a message edit) so what makes them cool and unique? (I think a really cool main benefit would be ability to inline the component in content maybe? That would be really nice)
• Would this expand into radio buttons? That seems to be quite common among configs, one of a few choices that wouldn't necessarily warrant a select menu

Anyways, I love the idea and it could pose a nice slim UI in comparison to buttons.

[JochCool]

Given that select menus have the same state for all users, I'd imagine that it'd be the same for checkboxes.

[ghost]

It would be useful for modals.

[i0bs]

With this, I feel like radio buttons/toggles should be heavily considered alongside the possibility of adding a checkbox component. Checkbox components sound like they could work similarly in mind with how select menus currently perform. Maybe this should be added like a JSON field style for a component so that you can stylize the way a button can appear as a checkbox, radio button, regular button and/or toggle?

[ghost]

Selects can be used for this.

[ghost]

About the toggles, see my thread to this post.

[JABirchall]

Just wanting to bump this, as I have recently ran into a modal im building which I feel needs a checkbox.

A modal im building which is for a moderation action for staff to fill in, and i wanted a checkbox to ban the user

• Ban the user

[ghost]

I'd like to also suggest Radio Buttons

I don't support this feature anymore, selects can be used.

[ghost]

How does discord expect us to create a boolean input?

Current Options

Select

They take a complete action row, which is too much for a simple toggle.
It is unnecessary to have a select with 2 elements, of which 1 is clickable.

Button

If so, what colors should I use for on and off? It can be really confusing and I can't find any combination that'll stand out - in my embed, this toggle is the most important button.

• Green for off (enable) Red for on (disable)
• Grey for off, Blue for on
• Grey for off, Green for on
• Blue for off, Green for on
• Red for off, Green for on
• Both blue
• both green
  Also, they cannot be used on modals, and will be usable by everyone on normal messages, which will require a kinda sketchy UX of ephemeral error responses.

Modal with Select

It may solve the select's length issue, but it'll keep all of the other issues, and the coloring issue of the button opening the modal (as you don't want opening the modal to be mandatory in order to view the current state), and will make the process longer and tedious.

Ephemeral with Select

This method will keep all of the modal's negatives, and isn't deletable after being used. Ephemerals shouldn't be used as modals.

Reactions

They have multiple issues:

• require more resources in order to follow their current state.
• cannot be use in ephemeral messages and modals
• each user can enable/disable the reaction on their own, so you can't know by who's reaction to count
• you can't have them on by default
• cannot be placed together with normal buttons in action rows

Conclusion

Seeing all above options are invalid, I suggest to add the

Switch

With a loading animation as shown below, to resemble the bot is thinking.
https://user-images.githubusercontent.com/59143021/188887011-2c4f4a60-78ba-41fd-82ea-73864ffc9c0c.mp4
In non-ephemeral messages, the switch's state will be synced between all users.
In modals, checkboxes should be rendered, since switches are for immediate actions, that do not require a save button.

[Pirulax]

Now I honestly don't have any other solution than using a TextInput inside modals (You can imagine how good of an UX that is), because there's no checkbox, the Select (that was okayish) is now removed too (See #5303).