Document channel_types in ApplicationCommandOption #3825
Conversation
| | required? | boolean | if the parameter is required or optional--default `false` | | ||
| | choices? | array of [application command option choice](#DOCS_INTERACTIONS_APPLICATION_COMMANDS/application-command-object-application-command-option-choice-structure) | choices for `STRING`, `INTEGER`, and `NUMBER` types for the user to pick from, max 25 | | ||
| | options? | array of [application command option](#DOCS_INTERACTIONS_APPLICATION_COMMANDS/application-command-object-application-command-option-structure) | if the option is a subcommand or subcommand group type, this nested options will be the parameters | | ||
| | channel_types? | array of [channel types](#DOCS_RESOURCES_CHANNEL/channel-object-channel-types) | if the option is a channel type, the channels shown will be restricted to these types | |
There was a problem hiding this comment.
are empty arrays treated weirdly?
There was a problem hiding this comment.
If you provide an empty array it will just use all channel types (at least from my testing that's what happened)
|
|
|
It seems passing a non-integer value attempts to coerce the value into an integer, and when that fails we get this error as expected. However, a value of true would be converted to 1. Furthermore, when sending null or undefined, it will set the type to be null (which is not documented as a valid type) and no channels will ever appear, preventing the command from being sent. |
|
it works in my lib when I set it null and ignore null on transmit. |
|
Oh whoops, should've specified, I meant sending null as an array value, not null as the value of the key itself Picture for further clarification of received data: |
|
Is this validated by the api or is it just client side? |
|
validated by the API (it's already live) |
|
#3825 (comment) is this intended? |
|
yes |
* discord/discord-api-docs#3825 * discordjs/discord.js#6640 * possible because of 9bd1d25 * i should really fix these typings
No description provided.