Description
As discussed on the Discord, it is the intent to implement class-based result handlers for every service, in pursuit of more accessible and customizable result handling. The following naming suggestions apply:
IApplicationCommandResultHandlerIComponentInteractionResultHandlerICommandResultHandler
- A footnote here, should this include
...Text... for clarity or take from preexisting naming?
These classes should be optional and not used by default. The original result handling logic can be retained, and the service provider can include the discovered objects on module creation, to be fetched at post-execution. (Can simply be done in HandleResultAsync default overload)
Unclear:
Do we want to support these types to be singleton or transient through something like an attribute? (scoped is irrelevant, it would adopt same logic as transient), or will we simply force either of the two on the recipient?
Description
As discussed on the Discord, it is the intent to implement class-based result handlers for every service, in pursuit of more accessible and customizable result handling. The following naming suggestions apply:
IApplicationCommandResultHandlerIComponentInteractionResultHandlerICommandResultHandler...Text...for clarity or take from preexisting naming?These classes should be optional and not used by default. The original result handling logic can be retained, and the service provider can include the discovered objects on module creation, to be fetched at post-execution. (Can simply be done in
HandleResultAsyncdefault overload)Unclear:
Do we want to support these types to be singleton or transient through something like an attribute? (scoped is irrelevant, it would adopt same logic as transient), or will we simply force either of the two on the recipient?