-
Notifications
You must be signed in to change notification settings - Fork 157
Buttons should declare dialog-opening intent upfront #311
Description
Problem Statement
The card ButtonElement has no way to signal that a button should open a dialog/modal rather than perform an inline action. This matters because platforms handle the two cases differently at the wire level:
Slack: Any button click provides a trigger_id, and the handler decides at runtime whether to call views.open(). Intent doesn't need to be declared upfront.
Teams: A button must use Action.Submit with msteams.type: "task/fetch" to trigger a task/fetch invoke (this is the event that gets triggered to ask the server what to render in the dialog). Regular Action.Submit (or Action.Execute) cannot return a task module. The wire format is different, so intent must be known at card-render time.
There's no way to defer this decision to the handler on Teams — the button's wire format determines the invoke path. The decision on what to render the dialog itself is up to the handler.
Proposed Solution
We could include an actionType as part of ButtonElement:
interface ButtonElement {
/** What happens when clicked. Default: "action" */
actionType?: "action" | "dialog";
disabled?: boolean;
id: string;
label: string;
style?: ButtonStyle;
type: "button";
value?: string;
}
This would put the intent up-front. In Teams, this would modify underlying button data to contain the necessary hint to trigger a dialog-open. Clients like Slack could choose to ignore it.
Alternatives Considered
No response
Use Case
Priority
Important
Contribution
- I am willing to help implement this feature
Additional Context
This is related to #306 work to support dialogs.