Is your feature request related to a problem?
After the recent scare regarding the submission bot no longer working due to Discord's new terms, it made me realize that the bot logic is pretty closely coupled to the way Discord works even though much of the functionality is largely independent of Discord. Not only is this pretty bad if Discord tries pulling more shenanigans in the future, but it also leads to a lot of parsing code interspersed in the actual logic of the bot which isn't super clean or scalable.
In the past, I've tried to build a couple of shared types which reduce the need to pass around Client and Message objects everywhere, but a lot of them are very specific to one part of the bot (SendableMessage, DownloadableMessage, etc) and really serve as shorthands more than actual abstractions over Discord's implementation of various systems.
Having a dedicated Discord layer would also make logging and debugging code easier since everything would pass through a very narrow interface.
Describe the feature you'd like
Build a dedicated "Discord" layer in which everything passes through using a shared interface, and use a platform-independent submission type in all actual business logic. Instead of relying on specific typed shorthands, having one interface which everything is based on would make it easier to add more features in the future and relatively easy to reimplement the discord API logic for another platform by swapping out the implementation.
Screenshot(s)
I've done some work on https://github.com/faithful-resource-pack/complibot-submissions/tree/feat/abstracted-discord, in particular https://github.com/Faithful-Resource-Pack/CompliBot-Submissions/blob/feat/abstracted-discord/src/submission/TextureSubmission.ts. I'm probably not going to go super hard down the OO route (submission objects should definitely be immutable for one) and it's a pretty rough sketch still but I think this is a good general direction to go in.
Notes
This would probably help make the code cleaner either way since all the Discord embed parsing logic (which there is a Lot of) would be completely separate from the actual implementation logic
Is your feature request related to a problem?
After the recent scare regarding the submission bot no longer working due to Discord's new terms, it made me realize that the bot logic is pretty closely coupled to the way Discord works even though much of the functionality is largely independent of Discord. Not only is this pretty bad if Discord tries pulling more shenanigans in the future, but it also leads to a lot of parsing code interspersed in the actual logic of the bot which isn't super clean or scalable.
In the past, I've tried to build a couple of shared types which reduce the need to pass around Client and Message objects everywhere, but a lot of them are very specific to one part of the bot (SendableMessage, DownloadableMessage, etc) and really serve as shorthands more than actual abstractions over Discord's implementation of various systems.
Having a dedicated Discord layer would also make logging and debugging code easier since everything would pass through a very narrow interface.
Describe the feature you'd like
Build a dedicated "Discord" layer in which everything passes through using a shared interface, and use a platform-independent submission type in all actual business logic. Instead of relying on specific typed shorthands, having one interface which everything is based on would make it easier to add more features in the future and relatively easy to reimplement the discord API logic for another platform by swapping out the implementation.
Screenshot(s)
I've done some work on https://github.com/faithful-resource-pack/complibot-submissions/tree/feat/abstracted-discord, in particular https://github.com/Faithful-Resource-Pack/CompliBot-Submissions/blob/feat/abstracted-discord/src/submission/TextureSubmission.ts. I'm probably not going to go super hard down the OO route (submission objects should definitely be immutable for one) and it's a pretty rough sketch still but I think this is a good general direction to go in.
Notes
This would probably help make the code cleaner either way since all the Discord embed parsing logic (which there is a Lot of) would be completely separate from the actual implementation logic