Sometimes you need to do something with the message (edit, pin/unpin, etc.), but you have only that message's id. Currently, the only exposed way to do this is by calling fetch_message method, which returns the Message object, and doing some operations with that. This variant isn't good because it does the api call which is unnecessary in this case. That can unreasonably slow our command.
The library should provide something like PartitalMessage class, which contains of all methods that require only message id. User must be able to create the instance of this class himself, it'll also be nice if it gets provided in RawReactionActionEvent payload.
You can use internal raw methods, like bot.http.remove_reaction, but they're not intended to be used by user. You can also create PartialMessage class yourself (see ?tag partial message on dpy server for more info).
The PartitalMessage class should exist. It'd be useful in case you have only message id and want to do some operations with this message.
Related to #2097
With the API changes introduced with events, it seems likely that we can expect less and less to be provided to bots at start- and a move to something more resembling stateless is probably going to happen. TO that end: it seems wise to start developing a good API to construct most if not all of the discord models currently in use by the user.
This has been brought up before and it's been planned, it's just the design space doesn't allow it to be easily done since the state has to be injected and there needs to be an injection point that allows it to happen whether transparently or not.
There are two options that I am impartial to:
There's also nothing forbidding both of these from co-existing but I'm unsure what method to take. Either way, the channel is required along with injecting the state.
With the API changes introduced with events, it seems likely that we can expect less and less to be provided to bots at start- and a move to something more resembling stateless is probably going to happen. TO that end: it seems wise to start developing a good API to construct most if not all of the discord models currently in use by the user.
User constructibility of all models is not a goal nor will it ever be. I would prefer if this issue request was limited in scope like it currently is.