How to resolve deprecation of Discord\Parts\Interactions\Interaction ?

[norkunas]

I understand that Interaction class was too generic and now subclasses are dispatched, but what's the point of the Interaction deprecation?

I have a generic solution to implement a custom InteractionHandler interface that is autodiscovered and can accept any interaction:

interface InteractionHandlerInterface
{
    /**
     * @return PromiseInterface<mixed>
     */
    public function handle(Interaction $interaction): PromiseInterface;
}

Now for me it does not matter which subobject it will call, as the each handler will reject if it does not support that interaction.

So to resolve deprecation I'd need to everywhere write Ping|ApplicationCommand|MessageComponent|ApplicationCommandAutocomplete|ModalSubmit $interaction which is cumbersome..

[valzargaming]

I don't believe it has been decided yet as to whether or not the interaction class will be made fully abstract. The deprecation notice is so that users can be prepared and update to use non-generic classes where relevant. Things like listening for the interaction class on an interaction create event is still completely valid, and the deprecation can be disregarded.

[shehi]

Why would you type anything with Ping|ApplicationCommand|MessageComponent|ApplicationCommandAutocomplete|ModalSubmit when all of those classes already share a common parent: Discord\Parts\Interactions\Interaction?! If your type-casting doesn't require specificity, just type it with parent type.

[norkunas]

Because when using static analysis it reports the deprecations?

[shehi]

Because when using static analysis it reports the deprecations?

Ah right. "Premature optimization" for you here. If something "hasn't been finally decided", why deprecate them @valzargaming ? "Just disregard" unfortunately won't cut for most of us. Could we please not make this kind of disruptive (in a negative connotation) changes to the codebase please? We should either undeprecate or if that doesn't work, put an interface to Interaction maybe?

[valzargaming]

Interaction objects are no longer created internally. The non-abstract class still exists as a fallback for the instance where Discord might implement a new Interaction type that exceeds the currently existing classes. The base class also does not contain documented definitions for properties specific to those types, and contains documented definitions for those that cannot exist in specific contexts. You should use the specific interaction type relevant to your use-case rather than assuming this change has no constructive purpose.

To clarify, the use of Interaction is deprecated for userland, but may be used internally as a fallback in this specific edge case that currently does not exist. I stated it hasn't been decided whether the class would become abstract, not deprecated, solely for the reason that we don't want functionality of this event listener to break if a new interaction type is added.

If the issue is that you don't know what type of interaction you're receiving, that can only be the case if you are utilizing the INTERACTION_CREATE event directly. You should be checking for the type and handling it appropriately.

[shehi]

I believe you still don't see the problem here: it's not about our "wrong"/"not-by-the-book" usage of Interaction, it's about the mere fact that this class which has to be mentioned/imported in many situations even if it's done for typing purposes, is deprecated, which breaks our static analysis tools.

Look at this:

This is my entrypoint code which passes all interactions to my handlers etc. I have to have some generic type here to attribute it to $interaction parameter. What do I do here so that the analyzers don't freak? You tell me. This isn't about some specific implementation of a certain use-case.

Or take this interface I have created which is a contract for all my interactable components:

How do you expect me to type the arguments of listener() method here, without breaking analyzers?!

[valzargaming]

So to resolve deprecation I'd need to everywhere write Ping|ApplicationCommand|MessageComponent|ApplicationCommandAutocomplete|ModalSubmit $interaction

You answered your own question here. But that’s not a real semantic problem, it’s a static analysis artifact. The code behaves correctly at runtime, however the analyzer is simply not flexible enough to understand the intended design. In other words, the code works as intended, the analyzer is what’s forcing the overly-specific union type.

[shehi]

@valzargaming , so if you add more and more interaction types, we have to go and update all our classes with these cumbersome union types?! You just shot SOLID in the head mate, and created shit ton of unnecessary work for people. You can't just outright blame the tool and technically ask us not to use it. You have to be flexible, better yet, sensible with your types.

[valzargaming]

To close this out: the deprecation notice has now been replaced with a since tag to avoid unnecessary disruption for static analysis tools.

The intention behind the original deprecation was to encourage use of the concrete interaction types now that the base Interaction class is no longer instantiated internally. That design direction hasn’t changed. Interaction is still a generic fallback for potential future types, and userland code can continue to rely on the specific subclasses when appropriate.

At the same time, the practical concerns raised here were valid. Static analyzers were treating the deprecation as a hard requirement to replace the parent type everywhere, which wasn’t the goal as it is still relevant to this one specific event. The updated documentation reflects this more accurately and avoids forcing users into cumbersome union types.

Thanks to everyone who raised the issue constructively.