types 3.0: breaking change for event payloads #1904
Labels
area:typescript
issues that specifically impact using the package from typescript projects
enhancement
M-T: A feature request for new functionality
pkg:types
applies to `@slack/types`
semver:major
Milestone
This would be a follow-up issue to tackle once slackapi/bolt-js#1395 is addressed; slackapi/bolt-js#1395 simply adds the existing, likely lacking, types for Events API payloads to the
types
package. This issue would be about breaking those payloads and include that in a new 3.0 release of@slack/types
.Summary
Improvements to
MessageEvent
Today,
MessageEvent
is a big union of different events Slack may send to apps, presumably that include some message information. Because it is a union, when using it as a type both in applications as well as frameworks (like bolt), only the common properties across all types in this union can be used. Some properties that would be expected to be present on messages are not common in this union today:text
andblocks
, for instance. We should study how this type is used in bolt and elsewhere, and consider a different approach to modeling message events. For example, perhaps a generics-based approach could better serve?Another problem when working with
MessageEvent
in TypeScript is the fact that one member of the union, theGenericMessageEvent
, hassubtype: undefined
. This causes major problems when trying to match against the union of all different kinds of messages, since many message subtype events have a defined string literalsubtype
.subtype: undefined
needs to get the 🔪 .TODO
Review Issues to Identify Pain Points
The following should be studied to determine the scope of what these breaking changes should include, in order to address developer pain points, and folded into the Summary section above in order to plan the changes:
subtype
message pattern filter formessage
handlers bolt-js#796message_replied
event missing text property in typescript #2025The text was updated successfully, but these errors were encountered: