-
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
Add missing message events & more type tests #832
Add missing message events & more type tests #832
Conversation
Codecov Report
@@ Coverage Diff @@
## main #832 +/- ##
=======================================
Coverage 65.89% 65.89%
=======================================
Files 13 13
Lines 1173 1173
Branches 343 343
=======================================
Hits 773 773
Misses 334 334
Partials 66 66 Continue to review full report at Codecov.
|
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.
left comments for reviewers and anyone who are interested
@@ -1,5 +1,14 @@ | |||
export * from './base-events'; | |||
export { BotMessageEvent, GenericMessageEvent } from './message-events'; | |||
export { |
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 the only change to the main code side.
|
||
const app = new App({ token: 'TOKEN', signingSecret: 'Signing Secret' }); | ||
|
||
expectType<void>( | ||
// TODO: Resolve the event type when having subtype in a listener constraint | ||
// app.message({pattern: 'foo', subtype: 'message_replied'}, async ({ message }) => {}); |
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.
We haven't agreed to implement this yet but this could be beneficial for some use cases. There are a few more things to consider:
- Should we enable developers to pass multiple subtypes here?
- If yes, the
message
object type in the scenario is not fully deterministic (it can be a bit more specific thanMessageEvent
but it's still a union type). - If no, for handling multiple types of subtyped message events, the right way is to have different event listeners for each subtype (some of internal code can be reused).
- If yes, the
- Is
pattern
a good key name for the pattern here? app.message<"message_replied">
vsapp.message(constraints
or should we support both?app.action
andapp.options
are not consistent at this point (refer to my comments below)
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.
I like the idea of having a constraints object here. subtype
in the constraints object makes sense. pattern
seems like a reasonable key name.
If we wanted to support multiple subtypes in one listener, what would that look like? An array for subtype: ['message_replied']
. Having an array in a constraint object would be new, but if using one listener for multiple subtypes is a usecase we think is common and should handle, it makes sense. Maybe @shaydewael can chime in on this.
My gut feeling is app.message(constraints
is more important. Does app.options
not support type
in constraints?
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.
We have another pull request making changes to the app.message
listener signature: #761
one more suggestion for this PR: can we add some type tests within type-tests/message.test-d.ts that illustrate (and validate) the expected usage?
Although Ankur asked the contributor to add more tests, we can handle the tests for the developer. Should we merge this PR before starting to work on the change we're discussing here?
My gut feeling is app.message(constraints is more important. Does app.options not support type in constraints?
As I mentioned the added tests for app.options
in this PR, it just does not work. I think we should make the developer experience consistent across the listeners but currently there are some gaps. Refer to the TODO/FIXME comments in this PR for details.
})); | ||
|
||
// block_suggestion | ||
expectType<void>(app.options<'block_suggestion'>({ action_id: 'a' }, async ({ options }) => { |
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.
Only app.options
has the string type parameter like this. app.view
and app.action
do not support the same way while they can determine payload type in accordance with type
in a constraint object.
Thanks for adding all of these great type tests. |
MessageDeletedEvent, | ||
ThreadBroadcastMessageEvent, | ||
MessageChangedEvent, | ||
EKMAccessDeniedMessageEvent, |
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.
Is there any chance we can export all the message events? Why is the list limited to a subset of events?
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.
@jestrada Do you have anything missing in your mind?
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.
Hey @seratch, thanks for the reply! Ya, all of the Channel*MessageEvent types are missing which makes it impossible to refer to import them. Is it possible to export all message event types.
Reference: https://github.com/slackapi/bolt-js/blob/main/src/types/events/message-events.ts#L3
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 I got the point. This is an easy fix. Thanks for pointing this out.
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.
submitted a PR to fix this: #1254
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 @seratch!
Summary
This pull request adds a few subtyped message events to top-level exports (currently, only
BotMessageEvent
is available infrom
@slack/bolt`). Also, as the very first step for #826 improvements, I've added a few more tests with TODO comments.Requirements (place an
x
in each[ ]
)