Option to use new buttons instead of reactions

[ririko5834]

Hi, could you please add option to use Discord buttons instead of reactions?

Info: https://discord.com/developers/docs/interactions/message-components

or can be done using https://www.npmjs.com/package/discord-buttons :

const { MessageButton } = require('discord-buttons');
let button = new MessageButton()
    .setLabel("Parcipate in this giveaway")
    .setStyle("blurple")
    .setEmoji("🎉") // giveaway reaction emoji
    .setID("giveaway_id")

message.channel.send({
    component: button,
    embed: giveawayembed
});

[Nico105]

Ahem the thing is, buttons do not count users, so we would have no option to roll the giveaway and determine winners. Theoretically we could use a event to manually save the users into an array. But if we would store that in the DB it would be way to big and also "unclicking" a button is not possible / another button would be needed etc. It just does not work out IMO.

[ririko5834]

You can save the winners in db, and it should be optional feature (disabled by default). When member clicked on the button and is already in database as parcipator, then it should be removed from database. And in there can be that the parcipated user count will be displayed on giveaway embed

[reinacchi]

I don't think it'll be a good idea and doesn't seems to work.

[Nico105]

You can save the winners in db, and it should be optional feature (disabled by default). When member clicked on the button and is already in database as parcipator, then it should be removed from database. And in there can be that the parcipated user count will be displayed on giveaway embed

Theoretically. But the count on the embed could only be updated with the interval because of rate limits, so you cannot know if you successfully participated or not. Also the db would be under heavy load cause we have to save every single participant. That could btw easily cause problems if let us say 20 or more users join in under 5s So it would be not scaleable when there are many gaws. And we also cannot detect people who entered a gaw when the bot is offline.

Ik it would look nice if we coulf use buttons, but they are just not intended for this task.

[ririko5834]

That's why it should be optional and siabled by default. And you can reply to the buttons to let the user know about parcipation using that wrapper:

await button.reply.send('Your entry for this giveaway was successfull!', true); //ephemeral message

This message will be visible just to user, and when user reloads their discord client, then the message will be not there.

[twlite]

using that wrapper:

await button.reply.send('Your entry for this giveaway was successfull!', true); //ephemeral message

are we talking about 3rd party package here?

[Nico105]

using that wrapper:

await button.reply.send('Your entry for this giveaway was successfull!', true); //ephemeral message

are we talking about 3rd party package here?

yeah, he means discord-buttons, but I would so or so only "consider" buttons when dc.js v13 is officially out.

[Dragonizedpizza]

Ahem the thing is, buttons do not count users, so we would have no option to roll the giveaway and determine winners. Theoretically we could use a event to manually save the users into an array. But if we would store that in the DB it would be way to big and also "unclicking" a button is not possible / another button would be needed etc. It just does not work out.

along with this, the iconic feature of counting giveaway reactions even after the process has been restarted wouldn't exist, since nothing would handle the interaction.

[Assassin-1234]

You can use This package instead to use Buttons with giveaways, visuals would be attached below

[Nico105]

I checked the code and it is using an array, like we talked about. And as said, this may be fine for a low number of giveaways with low participants but it won't scale well at least in my opinion.

[Assassin-1234]

I checked the code and it is using an array, like we talked about. And as said, this may be fine for a low number of giveaways with low participants but it won't scale well at least in my opinion.

you can implement a cache system to handle the database stuff. And array getting too long shouldnt be a problem afaik since an array can contain 2^32 elements 🙂

[twlite]

What if the bot is offline? With reactions, we could fetch it any time which would give us back every entries

[Lebyy]

Exactly if the bot is offline and someone clicks they won't be entered, we need to wait for Discord IF they make something like button click count and data then it would be possible

[AngeloCore]

You can use the button id, example When you send the button, the id is like 1, on every click you parse the id using parseInt and add 1

[twlite]

Ok but the question is, how would you handle that while/when the bot is offline?

[AngeloCore]

You can't, discord have to think abou that ¯\_(ツ)_/¯

[AngeloCore]

But if you wanna have big and strong bot, you must have 24/7 strong host

[twlite]

cough so called strong host can still have outages though.

Anyways, imo reactions are still far better than buttons in case of giveaways but it depends upon you on how you wanna implement it.

[AngeloCore]

I think the same

[typhoon11]

But if you wanna have big and strong bot, you must have 24/7 strong host

Big bot's doesn't mean they are always offline. Even dyno goes offline for maintenance and stuff, so what will guilds do at that time

[Assassin-1234]

they still maintain atleast 99% uptime throughout the months

[typhoon11]

they still maintain at least 99% uptime throughout the months

Yeah sure. These are some of the outages that were mentioned in their status and the shard outages are pretty common. I have my bot too that's in 600+ servers that go offline once in 2-3 weeks. So don't say big bots means always online. Btw I use AWS, don't think I am using some cheap or localhost.

[Assassin-1234]

my bot is in 1.7k servers with 2 shards running on digitalocean linux server which I pay 18$ per month for. Even if shards disconnect it comes back online after a few hours.

The discussion we're having is that we need a stable host for it to function properly, The more guilds you have, the less performance you will get

[Lebyy]

my bot is in 1.7k servers with 2 shards running on digitalocean linux server which I pay 18$ per month for. Even if shards disconnect it comes back online after a few hours.

The discussion we're having is that we need a stable host for it to function properly, The more guilds you have, the less performance you will get

It's not just about the uptime there are other downsides to it as well which Nico105 explained well.

[Nico105]

If discord somehow/somewhen makes additions to the system, then this can get rolled up again. But currently, I deem it as not made for giveaways, at least when using this package, since buttons would have to many shortcomings for implementing them (within this package).

[Dragonizedpizza]

I have a somewhat acceptable solution. Maybe you can make the functions to await input in the GiveawaysManager, and then let us extend it ourselves. Maybe you could make a Buttons.js in examples?

[Dragonizedpizza]

I can make a PR if you wish?

[Lebyy]

I have a somewhat acceptable solution. Maybe you can make the functions to await input in the GiveawaysManager, and then let us extend it ourselves. Maybe you could make a Buttons.js in examples?

But then again rises a question what if the bot is offline?

[Dragonizedpizza]

not discord-giveaways's problem, since you yourself decided to use buttons, and extended the class for it.

[Nico105]

I have a somewhat acceptable solution. Maybe you can make the functions to await input in the GiveawaysManager, and then let us extend it ourselves. Maybe you could make a Buttons.js in examples?

correct me if I'm wrong, but wouldn't you have to add the button to every message.edit() too? = we "would have to" make small extendable functions for quite a few things. + probably expose the giveaway class to be extended But then we could also just support it in house and don't to such half backed stuff. // which probably won't happen for mentioned reasons

that solution doesn't seem really good to me. Since we basically would have to write code for it, even though we say we don't support it.

and I guess if you really burn for buttons/want them, then it would make sense to just fork the package and support it for yourself, I guess. So you take the risks yourself. IMO

[ririko5834]

What will happen when bot was restartning when there is giveaway with buttons? You can make that button custom ID will be giveaway message ID and that users who reacted will be saved to database (in array) be their Discord IDs. When user that has already parcipated giveaway clicks on the button, remove it from database and reply that entry was removed. (replies should be customisable)

[reinacchi]

I don't know why we're still discussing this but I assumed there are few disadvantages within buttons that we might not notice for now. IMO we shouldn't be implementing this at all since it just won't work out all at some points.

As Nico said a forked of this project would be suitable to implement buttons if you want to support them instead of reactions.

[Nico105]

What will happen when bot was restartning when there is giveaway with buttons? You can make that button custom ID will be giveaway message ID and that users who reacted will be saved to database (in array) be their Discord IDs. When user that has already parcipated giveaway clicks on the button, remove it from database and reply that entry was removed. (replies should be customisable)

• when there is a restarts, nothing would happen, except that nobody can participate when the bot is offline.
• we already discussed the db saving, that would be the solution to store participants, yeah. but there would probably be db performance problems + maybe even corruptions I guess (depending on the db) (I am viewing this on a large scale)
• entry/remove messages are good and all, but that could lead to confusion, and maybe ratelimits, if there is an initial rush
• also now that we don't edit the message by default anymore, because of timestamps: if we would make a "counter" for participants in the embed, then that would only update per interval. and if we just wouldn't add the counter then there is no real way for the host to know how many people participated.

[Dragonizedpizza]

I have a somewhat acceptable solution. Maybe you can make the functions to await input in the GiveawaysManager, and then let us extend it ourselves. Maybe you could make a Buttons.js in examples?

correct me if I'm wrong, but wouldn't you have to add the button to every message.edit() too? = we "would have to" make small extendable functions for quite a few things. + probably expose the giveaway class to be extended But then we could also just support it in house and don't to such half backed stuff. // which probably won't happen for mentioned reasons

that solution doesn't seem really good to me. Since we basically would have to write code for it, even though we say we don't support it.

and I guess if you really burn for buttons/want them, then it would make sense to just fork the package and support it for yourself, I guess. So you take the risks yourself. IMO

you would, but this would allow for anything to be used as an entry system, even messages in a channel

[Dragonizedpizza]

the editing function can be inside a method in the GiveawaysManager

[Dragonizedpizza]

actually, I just ran this

const { Client, MessageActionRow, MessageButton } = require("discord.js"),
  client = new Client({ intents: 513 });

client.on("ready", async () => {
  console.log("ready!");
  const message = await (await client.channels.fetch("766190389362819072")).send({
    content: "hi",
    components: [
      new MessageActionRow().addComponents(
        new MessageButton().setStyle("SUCCESS").setCustomId("yeet").setLabel("yeet")
      ),
    ],
  });

  message.edit("bye");
});

client.login(require("./config.json").token);

and got this as output

[Dragonizedpizza]

I don't think components are affected unless you edit them

[Dragonizedpizza]

plus, what's wrong with exposing the giveaway class?

[Nico105]

plus, what's wrong with exposing the giveaway class?

nothing per se, (but people might break things then) but structuring/moving things for something which isn't really beneficial/"made" (as it is now) for the package, doesn't seem right/needed to me.

[ririko5834]

I don't think components are affected unless you edit them

When you dont specify compoenents in the message object, its not edited. If you add compoments: [] to the message object, they are removed from the message

[Dragonizedpizza]

plus, what's wrong with exposing the giveaway class?

nothing per se, (but people might break things then) but structuring/moving things for something which isn't really beneficial/"made" (as it is now) for the package, doesn't seem right/needed to me.

there's absolutely no reason why it would break tho, since you need to destructure it either way, you're just adding one more key to the object, plus, it would be very beneficial since it adds many more options for customization.

[Dragonizedpizza]

anyway, here's what I think you could do:

• Make message.edit and to await reactions a GiveawaysManager function/
• Make inhouse button support/
• Expose the Giveaways class and add a discord.js like Structures.extend

[reinacchi]

Maybe consider making a discussion topic about this instead of talking here?

[Dragonizedpizza]

@Androz2091 please share your opinions

[Dragonizedpizza]

@Nico105 since this is a valid issue, can this be re-opened?

[Nico105]

till we have androz's final word, okay...

[reinacchi]

Maybe consider making a discussion topic about this instead of talking here?

What about this? We can ask Androz to enable discussion and open one for this case.

[Dragonizedpizza]

uh

[Dragonizedpizza]

@Androz2091

[net-tech]

So is this going to be added or not?