laralove143 / sparkle_convenience

A wrapper over Twilight designed to make it more convenient to use

👋👋👋👋👋

Hello! I'm Lara, a 20 years old non-binary university student at METU trying to code despite my ADHD, nice to meet you!

---

🗣️🗣️🗣️🗣️🗣️

More 🗣️️

---

🧑‍💻🧑‍💻🧑‍💻🧑‍💻🧑‍💻

More 🧑‍💻

---

---

💼💼💼💼💼

Discord bots to make your life easier

In the team of Twilight, a Discord library for the Rust programming language

Volunteer at ÜNOG, an organization of university student game developers

---

🛠️🛠️🛠️🛠️🛠️

Timezoner

A Discord bot that converts times so that everyone sees them in their own timezone

Interchannel Message Mover

A Discord bot to move messages between channels

Message Bender

A Discord bot that lets you edit other people's messages

Auto Spoiler

A Discord bot that automatically puts possibly triggering words in spoilers

---

🎵🎵🎵🎵🎵

These are just my Apple Music playlists, here because I love music

_{I wish I could share my Apple Music profile but they're not supported where I live}

---

_{^{❤️🧡💛💚💙💜💛🤍💜🖤}}

sparkle_convenience's Issues

Remove use of anyhow

Using anyhow is not a good practice for a library, we could remove the dependency entirely depending on #2

make reply's fields public

i cant really see a reason that they shouldn't be, it'd make it easier to mutate the reply for example

return response in reply method

followups return Response<Message>, since replies only conditionally make a followup, it should return Option<Response<Message>>, when it is None should be documented

save whether an interaction was responded to and respond accordingly

followup is only allowed when the interaction was already responded to, while others are allowed when not. the logic should be done by the library, useful especially in showing user errors

methods:

1. add deferred: bool field to InteractionHandle, this means InteractionHandle has to be mutable and sent around by reference, adding code complexity and limitations
2. make deferred RefCell<bool> to obfuscate the mutability, with possible borrow errors (shouldn't happen since interactions shouldn't have unordered requests)
3. cursed method: add deferred_interactions: DashMap<String (token), bool> field to Bot
4. try followup, fall back to reply, the downsides are obviously making a possibly failing request and the users not getting as nice of an error
5. ???

gate anyhow behind a feature

the new updates reduce the crate's reliance on anyhow to just a few convenience methods, as such, for people that don't use anyhow, it can be put behind a default feature flag

reduce api surface of the crate

many methods are public because someone might use them, for the most users, this introduces many seemingly random items in the documentation

to be done before #14

proposal

deprecate these items and make them private in the next breaking release:

• error::ErrorExt: merge the use of this into #16
• error::extract::HttpErrorExt
• message::CreateMessageExt: consequently, rename message to dm or similar
• webhook::ExecuteWebhookExt

allow updating replies

followups send a new message, this is sometimes not preferred

execution

1. add an enum ReplyBehavior with variants Followup and Update
2. merge InteractionHandle::defer and InteractionHandle::defer_update_message, the difference determined by given ReplyBehavior
3. track the id of last sent followup in the handle, similar to #5
4. merge InteractionHandle::update_message and InteractionHandle::reply
5. add ReplyBehavior parameter to InteractionHandle::reply
6. add ReplyBehavior parameter to handle_error and handle_error_no_custom

alternative execution

1. implement first 4 steps in execution
2. add Reply::update method, similar to Reply::ephemeral
3. based on that, create a followup or update the last message

(InteractionHandle::defer would still require a ReplyBehavior parameter)

pros

shorter

self.reply(Reply::new().content("im content".to_owned()), ReplyBehavior::Followup).await?;
self.reply(Reply::new().content("im content".to_owned()).await?;

self.reply(Reply::new().content("im content".to_owned()), ReplyBehavior::Update).await?;
self.reply(Reply::new().content("im content".to_owned().update()).await?;

cons

• less expected
• less idiomatic?
• it means adding a field to Reply thats not part of a Response or Message

avoid breaking changes

the "changed" methods will actually be new methods, old ones being deprecated and calling new methods with ReplyBehavior::Followup, which is the current behavior

ignore internal discord errors

502s, api outages, timeouts etc. cant be fixed by the bot's devs so some people might want to ignore them

these are different than the currently ignored errors in that its still a failed operation on the user's side, meaning it should be customizable whether these errors are ignored

automatically check for attachments and auto-ack

attachments usually take long enough to upload that they will always require a defer, so automatically ack'ing them would be good

remove `anyhow` from the api

the crate uses anyhow::Error to combine internal errors, UserErrors and custom errors, to handle user errors the user has to downcast the error to UserError or their custom error themself, this isnt ideal

proposal

• change UserError to UserError<C> with added variants Custom(C) and Internal(anyhow::Error)
• implement From<anyhow::Error> for UserError, which does the downcasting itself
• add with_permissions method to UserError which overwrites the UserError::MissingPermissions permission and returns it
• mention the from implementation in the documentation of methods in #16

add method to extract values from modals

while it's rather simple it ends up being a bit of boilerplate when extracting multiple components' values, im not sure if theres a need for this for other components, since always have a single value

it should be a trait on ModalInteractionData that simply takes a custom_id and returns an option, this has the limitation of returning a reference so that it doesnt consume it (since it probably has more components)

the trickier bit is consuming the data and returning a [String] so that it can be destructed, it could be collected to a HashMap or struct but former is overhead and latter requires proc macros and for the user to create a struct

this can be done using const generics

fn values<const N: usize>(self, custom_ids: [&str; N]) -> [String; N];

although this requires that the users provide the custom_ids statically, it can be used like

let [val1, val2] = data.values(["val1", "val2"])?; // returns error if not enough values

update docs on log

it currently says that theres an attachment if the message is too long, it doesnt mention that the preview is still available in the content

change `handle_error` to `handle_user_error`

while there isn't many ways to hande user errors, there's many ways to handle internal errors, you may want to use a tracing crate, log your own errors for metrics etc

• deprecates handle_error since the only addition would be to simply log the errors with Bot::log
• removes printing and file-logging functionality, since those aren't discord-related

closing #12 in favor of this

Interaction Modal Bug | 50035 | Each Text Input should be Wrapped in an Row

I have found a bug in the file:
https://github.com/laralove143/sparkle-convenience/blob/main/src/interaction.rs#L236

If you use only one row for all TextInput you get the following error:

body_string: "{\"code\": 50035, \"errors\": {\"data\": {\"components\": {\"0\": {\"componentsage\": \"The specified component exceeds the maximum width\"}]}}}}}}, \"message\": \"Invalid Form Body\"}

each TextInput should be in its own row

Make `err::with_permissions` consume and return `Self`

My worries of losing data by consuming an error seem to be invalid, it should follow the builder pattern for convenience

allow log method to not print

many people use logging crates to print errors and do more, Bot should have a log_disable_print method to disable printing

add timed messages

when ephemeral messages arent possible, its common practice to send a message that deletes itself after a timeout

breaking because it needs Bot.client to be Arc<Client> instead of Client

change/remove tokio's `rt-multi-thread` feature

if it's necessary, change it to rt, if not, remove it entirely

add transparent features for twilight features

allow users to set which features will be set in twilight dependencies

break down the main page of documentation

the main page will get increasingly longer as new features are added, to declutter it and make navigation easier, each feature should be put in its own module

• axum's documentation is a good example, it also has a table of contents
• this would mean the docs can be built from the readme and crates.io can get better documentation too

reduce features to those that are needed

users of this library will already enable the required features, so transparent features aren't needed

suggestion by @Gelbpunkt

provide a preview of the log in message content

the current approach is to put the log in the message content if it fits or the attachment if it doesnt, when a message with the attachment is given, it doesn't give us any info about the log without looking at the attachment, the content could contain the first 100 characters as preview and include the same attachment as before

this isnt enough to bump the version so it'll target the rc branch

Add error handlers specific to interactions and messages

An error handling method should be added to Bot (for messages) and InteractionHandle that takes a Reply (user constructed for customizability), Error and a type parameter for CustomError (to check if the error is internal), which does the ignoring, replying and logging all in one

The caveat is that it'd only work with anyhow::Error since the required traits are only implemented for that

add time to logs

should be configurable and be specific to ones written to logs, since most tools to check a process's stdout (like journalctl) track timing themselves, or scope should be configurable too

make reply take `Into<String>`

Reply is a convenience/utility abstraction, its common practice to accept both &str and String to make allocations implicit, which is usually a bad thing but not in this case

this won't be considered breaking since it only breaks "im a str".into()

dont own `user_error` in report error functions

i dont believe its actually consumed