Add Generic Interaction types

[lisekilis]

Feature

Generic Interaction types that would allow the casting of interaction types based on known data of the command that produced the interaction
This would significantly improve type safety and remove pointless checks in the handling of incoming discord interactions

Ideal solution or implementation

An ideal solution would be the addition of generic types like
GenericAPIInteraction<T>
GenericAPIChatInputApplicationCommandInteraction<T>,
or somehting of this sorts

Specific implementation doesn't matter as long as there is a way to create Interaction types from known command data

Alternative solutions or implementations

No response

Other context

Example of code that would benefit this change:
(this is not exact code but just something to paint the idea)

const exampleCommandData = {
	data: {
		name: 'config',
		description: 'Configure the app settings',
		type: ApplicationCommandType.ChatInput,
		options: [
			{
				name: 'mod role',
				type: ApplicationCommandOptionType.Role,
				description: 'Set the mod role',
			},
		],
	},
};

const executeExample = (interaction: APIChatInputApplicationCommandInteraction) => {
	// interaction here would be a generic that would take the type of commandData passed in instead of being a APIChatInputApplicationCommandInteraction
	const name = interaction.data.name; // "config" instead of string

	const modRole = interaction.data.options?.find((opt) => opt.name === 'mod role'); //
	// options wouldn't be a possibly null generic array but rather an array of the specific options passed in
	if (!modRole || modRole.type !== ApplicationCommandOptionType.Role) {
		return messageResponse('Please provide a valid role', MessageFlags.Ephemeral);
	}
	modRole.value; // role ID instead of string

	// some code to set mod role

	return messageResponse(`Config command executed: ${name}`, MessageFlags.Ephemeral);
};

type InvokedInteractionData = typeof exampleCommandData;

type ExampleCommandInteraction = GenericAPIChatInputApplicationCommandInteraction<InvokedInteractionData>;

const executeExampleWithGenericInteractions = (interaction: ExampleCommandInteraction) => {
	const name = interaction.data.name; // this is just "config"

	const modRole = interaction.data.options.find((opt) => opt.name === 'mod role'); //
	// options wouldn't be a possibly null generic array but rather an array of the specific options passed in
	
	// if (!modRole || modRole.type !== ApplicationCommandOptionType.Role) {
	// 	return messageResponse('Please provide a valid role', MessageFlags.Ephemeral);
	// } // This check is not needed as the type system already knows the type of modRole

	modRole.value; // now correctly typed as role ID instead of string

	// some code to set mod role

	return messageResponse(`Config command executed: ${name}`, MessageFlags.Ephemeral);
};

[Qjuh]

I don't see the benefit for your example. You'd need to check the command name either way to make sure the type is correct before you can call that function. And in that function you already know the value of name etc. and could get it directly from data. What's gained here?

[lisekilis]

I don't see the benefit for your example. You'd need to check the command name either way to make sure the type is correct before you can call that function. And in that function you already know the value of name etc. and could get it directly from data. What's gained here?

I am terrible at explaining stuff but I'll try either way
name is something that you know either way, yes. That is what I use to identify where the interaction originated,
however when working with options, subcommands etc. Having the language server actually know what is happening would be nice. Achieving that without having to perform essentially pointless checks just to make the language server stop screaming that I'm accessing an option's value, even tho I know that it exists and what type it is, because It's defined literally 20 lines earlier. The language server just doesn't know stuff I do and generics would help fix that without adding a ton of checks every time you want something to have an option

It's basically moving the work from runtime to transpile time (?)

[tipakA]

I feel like this would make sense exclusively if you could somehow guarantee that your object definition of the command is the only "version" of that command that is valid at all times. By design, unlike for example message content commands where entire thing is contained within your app's process, Discord's interaction commands cannot provide such guarantee as creating or updating a command can happen completely out of band from the process or even codebase that will later on receive those commands.

This seems like the same thing that makes http libraries not provide such generics to their fetch functions, because as you say, such generic only works at transpile time, but it's applied to something that's inherently runtime-sided. If an API returns something now, doesn't mean it will do that for the end of time, or until you change your type in your generic, whichever happens earlier.