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