-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup Lambda example and docs around proccessBeforeResponse
#1229
Cleanup Lambda example and docs around proccessBeforeResponse
#1229
Conversation
General feedback:
|
I'd also be happy to look into raising a separate PR with some overload signatures for the App constructor to exclude |
@@ -140,12 +140,7 @@ const awsLambdaReceiver = new AwsLambdaReceiver({ | |||
// Initializes your app with your bot token and the AWS Lambda ready receiver | |||
const app = new App({ | |||
token: process.env.SLACK_BOT_TOKEN, | |||
receiver: awsLambdaReceiver, | |||
// The `processBeforeResponse` option is required for all FaaS environments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of deleting this, we want to say "If you go with AwsLambdaReceiver
like this example does, you can omit processBeforeResponse: true
. But, if you use other receivers such as ExpressReceiver for OAuth flow support, processBeforeResponse: true
is required."
See also:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I'll rework this then.
@@ -89,7 +89,7 @@ Bolt includes a collection of initialization options to customize apps. There ar | |||
| :---: | :--- | | |||
| `signingSecret` | A `string` from your app's configuration (under "Basic Information") which verifies that incoming events are coming from Slack | | |||
| `endpoints` | A `string` or `object` that specifies the endpoint(s) that the receiver will listen for incoming requests from Slack. Currently, the only key for the object is `key`, the value of which is the customizable endpoint (ex: `/myapp/events`). **By default, all events are sent to the `/slack/events` endpoint** | | |||
| `processBeforeResponse` | `boolean` that determines whether events should be immediately acknowledged. This is primarily useful when running apps on FaaS to ensure events listeners don't unexpectedly terminate by setting it to `true`. Defaults to `false`. | | |||
| `processBeforeResponse` | `boolean` that determines whether events should be immediately acknowledged. This is primarily useful when running apps on FaaS since listeners will terminate immediately once the request has completed. When set to `true` it will defer sending the acknowledgement until after your handlers run to prevent early termination. Defaults to `false`. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a clearer description. Thanks for the suggestion 👍
docs/_tutorials/reference.md
Outdated
@@ -98,7 +98,7 @@ Bolt includes a collection of initialization options to customize apps. There ar | |||
| `installerOptions` | Optional object that can be used to customize [the default OAuth support](/bolt-js/concepts#authenticating-oauth). Read more in the OAuth documentation. | | |||
|
|||
### App options | |||
App options are passed into the `App` constructor. | |||
App options are passed into the `App` constructor. The `App` constructor also accepts [`HttpReceiver`](#receiver-options) options which will be used to initialise a [Receiever](/bolt-js/concepts#receiver) when the `receiver` argument is `undefined` and are ignored otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioning HttpReceiver
options is correct but it can be confusing for the people new to bolt-js. We can simply say the receiver options above are also available in the argument list.
App options are passed into the `App` constructor. The `App` constructor also accepts [`HttpReceiver`](#receiver-options) options which will be used to initialise a [Receiever](/bolt-js/concepts#receiver) when the `receiver` argument is `undefined` and are ignored otherwise. | |
App options are passed into the `App` constructor. Also, when the `receiver` argument is `undefined`, the `App` constructor accepts [the above receiver options](#receiver-options) to initialize an appropriate `Receiver` for you. ` |
I didn't mention HTTPReceiver
because it can be SocketModeReceiver
if socketMode: true
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right. I had my blinders on when making this change I didn't realise it was the generic Receiver
options and not specific to HttpReceiver
. How would you feel about mentioning socketMode
and calling out the specific Receivers that could be constructed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that sounds good to me 👍
// It allows Bolt methods (e.g. `app.message`) to handle a Slack request | ||
// before the Bolt framework responds to the request (e.g. `ack()`). This is | ||
// important because FaaS immediately terminate handlers after the response. | ||
processBeforeResponse: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment out this option is fine but as I mentioned above, we would like to keep the comment for OAuth flow use cases.
See also:
@@ -43,10 +38,9 @@ app.message('hello', async ({ message, say }) => { | |||
|
|||
// Listens for an action from a button click | |||
app.action('button_click', async ({ body, ack, say }) => { | |||
await say(`<@${body.user.id}> clicked the button`); | |||
|
|||
// Acknowledge the action after say() to exit the Lambda process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Indeed, this comment can be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more minor request 🙇
Standardize on American spelling of initialize Co-authored-by: Kazuhiro Sera <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your time and efforts!
Thank you for making it a great experience! It shouldn't be unusual, and yet... |
Summary
The information supplied around
processBeforeResponse
was rather confusing and contradictory.processBeforeResponse
to the App constructor, but the AwsLambdaReciever class implements the correct behaviour & the argument isn't used in the constructor unless there isn't a receiver passed. Therefore I removed the argument and comment.ack
at the end to respond to the request, but this contradicts other documentation that says to call it as early as possible, and the receiver will defer it until afterwards anyway. So I've movedack
to the top, otherwise I would've reworded the comment above it.processBeforeResponse
to explain the behaviour more explicitlyHttpReceiver
arguments being passed to theApp
constructor under theApp options
header and explained how those arguments are used.Requirements (place an
x
in each[ ]
)