The ack() function should accept any value that is acceptable to respond to an incoming HTTP request. In the context of view submissions, there are a few response_actions that are acceptable, but currently do not work because the ack utility is incorrectly typed to take RespondArguments.
The solution is likely to use the AckFn<T> type to describe the additional response_action payloads:
updatepushclearerrorshttps://api.slack.com/surfaces/modals/using#modifying
https://api.slack.com/surfaces/modals/using#displaying_errors
x in each of the [ ])Filling out the following details about bugs will help us solve your issue sooner.
package version: 1.4.1
node version: all
OS version(s): all
ack({ response_action: "clear" }) in the listener.The TypeScript typechecker is happy.
The TypeScript typechecker is sad.
Has this been fixed? How am I supposed to send an error message to a modal upon submission using bolt?
@jacklein Unfortunately, it hasn't been fixed yet.
... I know this is not a preferable workaround but the only thing TypeScript users can do as a workaround is cast the response to any until it has been fixed in future versions.
app.view('callback_id', ({ ack }) => {
ack({
response_action: 'errors',
errors: []
} as any /* Tentative workaround for https://github.com/slackapi/bolt/issues/305 */);
});
I will take look at this issue. I'm also a big fan of TS.
@seratch I'm using node.js not typescript (I'm not at all familiar with typescript), is there any workaround for plain javascript?
@jacklein In JavaScript, there is no obstacle. You can give respond_action and errors like this:
https://github.com/seratch/bolt-starter/blob/5e1e4e49279856d70a7d4b8824a24d0056b33206/index.js#L143-L146
const errors = {};
if (title.length <= 5) {
errors['input-title'] = 'Title must be longer than 5 characters'
}
if (Object.entries(errors).length > 0) {
ack({
response_action: 'errors',
errors: errors
});
} else {
ack(); // close this modal - or also possible to set `response_action: 'clear'`
}
@seratch You really saved my life with that example code. Thank you, I really appreciate the help.
One potential bug I would like to point out is I had a group of date pickers that looks like:
{
"type": "actions",
"block_id": "date_select",
"elements": [
{
"type": "datepicker",
"action_id": "departure_date",
"placeholder": {
"type": "plain_text",
"text": "Departure date"
},
},
{
"type": "datepicker",
"action_id": "return_date",
"placeholder": {
"type": "plain_text",
"text": "Return date"
},
},
]
}
and the error message wasn't working for date_select. Is this to be expected since it's an action type?
@jacklein
An actions block cannot be a part of view_submission data. Use input blocks instead:
{
"type": "input",
"block_id": "departure_date",
"element": {
"type": "datepicker",
"action_id": "input",
"placeholder": {
"type": "plain_text",
"text": "Departure date"
},
},
"label": {
"type": "plain_text",
"text": "Departure date",
"emoji": true
}
},
{
"type": "input",
"block_id": "return_date",
"element": {
"type": "datepicker",
"action_id": "input",
"placeholder": {
"type": "plain_text",
"text": "Return date"
},
},
"label": {
"type": "plain_text",
"text": "Return date",
"emoji": true
}
}
@seratch Awesome! Thanks again, really appreciate your help!
Most helpful comment
@jacklein Unfortunately, it hasn't been fixed yet.
... I know this is not a preferable workaround but the only thing TypeScript users can do as a workaround is cast the response to
anyuntil it has been fixed in future versions.I will take look at this issue. I'm also a big fan of TS.