Make Interaction#editReply and Interaction#followUp await for Interaction#deferUpdate and Interaction#deferReply about discord.js HOT 6 CLOSED

I've looked at your example implementation - it's a little confusing to read due to the number of completely unnecessary changes away from async functions. If I'm interpreting it correctly, it would appear that the developer still has to manually call deferReply, but then discord.js would be responsible for awaiting it internally?

This could be considered over-opinionated code - it should remain up to the developer to implement rather than abstracted away inside a library where they have no control. Given that the implementation on the developer's side is a single await keyword rather than... whatever this is, I don't think we'll be adding this feature.

from discord.js.

a single await keyword

yeah, there's a lot of examples look like this:

await interaction.deferReply();
await asyncOperation();
interaction.followUp("message");

yes, that's a single await keyword. but let's assume that deferReply takes t1 of time, and asyncOperation takes t2 of time, then the example above will take t1 + t2 of time, and i don't like that.
to make it take max(t1, t2) of time, the implementation would be:

const defer = interaction.deferReply();
await asyncOperation();
await defer;
interaction.followUp("message");

or

const operation = asyncOperation();
await interaction.deferReply();
await operation;
interaction.followUp("message");

or

await Promise.all([interaction.deferReply(), asyncOperation()]);
interaction.followUp("message");

now the code looks a bit complicated than before, which i think it's unnecessary to do that everywhere (reduce repetitive code), so i already made a mixin for it for myself, then my code will be cleaner:

interaction.deferReply();
await asyncOperation();
interaction.followUp("message");

and i thought it would be great to just implement it on d.js.
or maybe... add an option in ClientOptions called awaitForDefer if it's too over-opinionated, i still think it would be a good feature.

from discord.js.

All of your examples ignore both the order of execution and individual successful execution - which is fine if you don't care. However, they carry the risk that you will defer without the asyncOperation completing successfully, or execute an asyncOperation without the defer completing successfully.

You're welcome to manage this in your own code where you have the control to do so, as vlad suggested. Taking that design choice away from the developer and putting it inside the library would be bad practice.

Making your code "cleaner" does not make it better.

from discord.js.

Can you explain a bit more what you mean by this? do you have any use cases for this change?

from discord.js.

This sounds like something you could implement yourself in a utility function, and not something the library should be responsible for doing 👀

from discord.js.

Understood. Thanks for the explanations!

from discord.js.