Support yielding in interaction handler

[davfsa]

Summary

Allow for proper defering in interaction handling in RESTBot

Example code:

async def handle_command(interaction):
    yield interaction.build_deferred_response()

    await interaction.edit_initial_response("Hi!")

Checklist

• I have run nox and all the pipelines have passed.
• I have made unittests according to the code I have added/modified/deleted.

[FasterSpeeding]

Who is this feature for, shouldn't ppl just be using a command/component client instead of doing it raw (esp since this interface is more designed for clients to hook onto)?

Allow for proper deferring in interaction handling in RESTBot

Also this is kind of misleading, you could always defer and then give follow up responses just using tasks

[davfsa]

Also this is kind of misleading, you could always defer and then give follow up responses just using tasks

This is exactly what this process is doing. It provides an easier way to create a task for followups by just using the same handler

[thesadru]

Wouldn't it potentially be better to provide this as a helper wrapper function? Could still be implicitly subscribe(aiterator()) but explicitly as subscribe(utils.somewrap(aiterator)). Should declutter the already pretty big method.

[davfsa]

Wouldn't it potentially be better to provide this as a helper wrapper function? Could still be implicitly subscribe(aiterator()) but explicitly as subscribe(utils.somewrap(aiterator)). Should declutter the already pretty big method.

I am not sure what you mean here. a) How would a helper function aid here? b) What would this declutter?

[thesadru]

If you could wrap the generator to a standard async function when being registered it should be able to abstract stuff away from the on_interaction method.

[davfsa]

If you could wrap the generator to a standard async function when being registered it should be able to abstract stuff away from the on_interaction method.

Considering we would have to create a task anyways and then store it in a list (because the function may be called again before the generator completed), we could end up with a bunch of objects that act as async functions that each store a list of tasks of running generators, it would be much more expensive than the 5-6 lines this adds to an existing function.

I would much rather keep it the way it is atm, if we were to go this way.