feat: add support to @slack/web-api for work objects#2231
Conversation
f24a1df to
7849554
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2231 +/- ##
=======================================
Coverage 93.01% 93.02%
=======================================
Files 40 40
Lines 11111 11124 +13
Branches 713 713
=======================================
+ Hits 10335 10348 +13
Misses 764 764
Partials 12 12
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
9073126 to
a1ef919
Compare
a1ef919 to
dde54aa
Compare
fabc16e to
9e8988b
Compare
0517996 to
54b1211
Compare
54b1211 to
da092d5
Compare
d759247 to
24ecda6
Compare
WilliamBergamin
left a comment
There was a problem hiding this comment.
Great work putting all this together 🙏 types are hard!!
I've left a few comment and questions let me know what you think
| Parse & | ||
| LinkNames & | ||
| Metadata & | ||
| ChatPostMessageMetadata & |
There was a problem hiding this comment.
❓ Just want to validate that I'm understanding correctly, this updates ChatPostMessageArguments from
interface ChatPostMessageArguments {
...
metadata?: {
event_type: string;
event_payload: {
[key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
};
}To
interface ChatPostMessageArguments {
...
metadata?: {
event_type?: string;
event_payload?: {
[key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
};
entities?: EntityMetadata[];
}Since this type is used to define and input for a function, making event_type and event_payload optional should not be a breaking change?
There was a problem hiding this comment.
Yup; what I'm trying to show is that one can provide event and / or entity metadata in chat.postMessage
interface ChatPostMessageArguments {
...
metadata?: {
// if providing event metadata, both of these params are still required (but they're optional in the type bc one can provide entity metadata instead)
event_type: string;
event_payload: {
[key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
};
AND / OR
// if providing entity metadata, this param is required (but it's optional in the type bc one can provide event metadata instead)
entities: EntityMetadata[];
}
Since this type is used to define and input for a function, making event_type and event_payload optional should not be a breaking change?
Passing an object into the metadata param with just event_type and event_payload is still valid and should still be accepted by the SDK; if users are typing the object as Metadata though they would need to change that to ChatPostMessageMetadata. Similar thing came up for the Java update; changing the type of an existing field does seem like a breaking change 😅 Will work object support require a major version bump because of this?
There was a problem hiding this comment.
Will work object support require a major version bump because of this?
The the Java SDK I need to take a look there might be a way around this
| type BlockKitUnfurls = { | ||
| /** | ||
| * @description Object with keys set to URLs featured in the message, pointing to their unfurl | ||
| * blocks or message attachments. | ||
| */ | ||
| unfurls: LinkUnfurls; | ||
| }; |
There was a problem hiding this comment.
++ on praise for this 🙏
| */ | ||
| metadata: Partial<MessageMetadata> & { | ||
| entities: EntityMetadata[]; | ||
| }; |
There was a problem hiding this comment.
QQ: In ChatPostMessageMetadata, entities is optional, just want to confirm that here is should be required
|
I'm not sure what's going on with the failing tests in the cli-test package; It seems like the object being passed in matches the interface Edit: resolved! |
bea1441 to
c0cc1f6
Compare
packages/web-api/package.json
Outdated
| "dependencies": { | ||
| "@slack/logger": "^4.0.0", | ||
| "@slack/types": "^2.17.0", | ||
| "@slack/types": "2.18.0", |
WilliamBergamin
left a comment
There was a problem hiding this comment.
Quick change actually
Co-authored-by: William Bergamin <[email protected]>
Summary
Follow-up to PR 2412
This PR adds the following support for work objects:
chat.unfurlorchat.postMessageto accept entity metadataRequirements (place an
xin each[ ])