Modals: Make Unsafe Less Useful

[gdude2002]

While chatting with @AugustoMegener, I had an idea regarding how Modals are currently implemented - why can't each type that supports modals support passing their relevant data to the Modal constructor?

Like, if we look at the String-based select menu types, EphemeralStringSelectMenu takes (() -> M)? as the Modal builder, but I don't see why it couldn't take, for example, ((List<String>) -> M)?.

I think we could implement this with minimal friction, and I also think we could do it without breaking the current API. However, I'm currently working on something else, so I've created this reminder issue. I'll look into this later on!

[gdude2002]

I've been looking into doing this, and while I don't mind the busywork behind it, I've realised that it's difficult to do this reasonably because of how Discord works.

Essentially, all interaction-based contexts contain the initial interaction response. This is an issue because a Modal must be sent as the first interaction response, meaning a component cannot be created before we attempt to send a Modal. As the contexts are responsible for converting component values to rich types, this creates a circular dependency that can't easily be fixed without significantly complicating the API and worsening the UX.

This is a bit simpler for commands, which have their arguments parsed before the context is created. However, I don't want to implement a Modal API for commands that isn't consistent with the rest of the Modal APIs.

As a result, I'll be shelving this idea for now, at least until I can think of a better approach.