You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Within the Discord API there are a number of components such as buttons, select menu which allow an action to be performed as a result of another action from a user.
Example:
A new member joins the Discord server, under their welcome message is a button that sends a Hello ${member.username} message when a user clicks on it.
In this example, we can break the process down into several steps:
Sending a message containing the button component
Click by a user
Sending a Hello ${member.username} message
In this process, we receive the action of the click (2) thanks to the interactionCreate event via the websocket and then, once redispatched, the developer can interact with it via a reaction.
This process is not practical for a developer who has to break down a "unified" flow into several listeners.
Proposal
In order to simplify the integration of this flow, we would like to propose an approach that allows the action performed on a component to be grouped with a handler.
We can therefore envisage a simple approach as shown below:
final myButton =Button.primary(
uniqueId:'1234',
label:'Clic me',
handle: (ctx) =>print(ctx)
);
To enable the handler to be retrieved and executed, we need to store it using our IoC in a dedicated service in a simple format.
If the button is sent a first time with a message during the application's lifecycle, then the trigger will find the association between uniqueId and the associated handler.
If the function containing the button is never called, the ComponentHandler association will not exist and no action will be executed.
Solution
To solve this problem, we can consider 2 approaches:
We need to declare the components in a file read during the boot time which would allow the systematic and automatic registration (via a constructor?) of the ComponentHandler as soon as it is started.
The same principle as above, but with explicit registration in the client builder.
The text was updated successfully, but these errors were encountered:
Context
Within the Discord API there are a number of components such as
buttons
,select menu
which allow an action to be performed as a result of another action from a user.In this example, we can break the process down into several steps:
button
componentHello ${member.username}
messageIn this process, we receive the action of the click (2) thanks to the
interactionCreate
event via the websocket and then, once redispatched, the developer can interact with it via a reaction.This process is not practical for a developer who has to break down a "unified" flow into several listeners.
Proposal
In order to simplify the integration of this flow, we would like to propose an approach that allows the action performed on a component to be grouped with a handler.
We can therefore envisage a simple approach as shown below:
To enable the handler to be retrieved and executed, we need to store it using our IoC in a dedicated service in a simple format.
If the button is sent a first time with a message during the application's lifecycle, then the trigger will find the association between
uniqueId
and the associated handler.A class-based approach could be considered:
Problem
If the function containing the button is never called, the
ComponentHandler
association will not exist and no action will be executed.Solution
To solve this problem, we can consider 2 approaches:
boot time
which would allow the systematic and automatic registration (via a constructor?) of theComponentHandler
as soon as it is started.The text was updated successfully, but these errors were encountered: