Node-slack-sdk: Accept response_url to send messages

[aoberoi]

Description

Interactive components (menus, buttons, dialogs, and actions) and slash commands produce response_url values. It would be great if this package offered a shortcut for invoking those URLs so there wasn't a need to directly include an HTTP library and format the request body.

Requirements (place an x in each of the [ ])

• [x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [x] I've read and agree to the Code of Conduct.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

[LaurentVB]

Hello,

Came here to open this issue, found that you already thought about adding it.
It seems a bit weird to use the WebClient everywhere in my code, and just sometimes having to

const fetch = require('node-fetch');

async function respond(responseUrl, message) {
  return fetch(responseUrl, {
    method: 'POST',
    body: JSON.stringify(message)
  });
}
...

Just to get the ball rolling, what about a static .respond(response_url, message) method on the WebClient?

const {WebClient} = require('@slack/client);

WebClient.respond(response_url, {text: 'This is my response'});

Cheers,

Laurent

[aoberoi]

thanks for the proposal @LaurentVB. this seems pretty reasonable to me.

i thought about this some more and realized that the IncomingWebhook class is essentially already a wrapper around a response_url. although conceptually, an incoming webhook and response URL are two different things, functionally they are more or less the same. that is, depending on where the response URL originated from (a slash command, a dialog submission, a button click) the arguments might differ, but the code to invoke the URL is the exact same.

in light of that information, i wonder if it makes sense for the WebClient to internally depend on IncomingWebhook and offer the static method as just an alias for constructing the an instance and invoking send() immediately.

[LaurentVB]

Hello @aoberoi , thanks for your reply.
On a code reuse perspective, it totally makes sense. But as you said the two are very different conceptually.
Wouldn't it be more correct to have them both depend and build upon a common UrlInvoker or whatever you would name it?

[aoberoi]

Actually, I'm going to back-pedal on my previous comment. The less the implementation depends on IncomingWebhook, the better. If they both depend on some UrlInvoker, that might be okay (depending on how much functionality exactly is pushed down to that object). But I don't think its a priority to solve this problem together IncomingWebhook. IMHO the IncomingWebhook abstraction hasn't aged well, and we should think about how we might do it completely differently today (and that should be a separate GH issue if that's what someone needs).

[sokoloff06]

Hi there!

Are there any updates on this? Was pretty surprised to discover that there is no separate method or any argument to pass response_url to WebClient.

I see there is not much of activity here so wanted to show that people are still interested in this 👍