feat(slack/send-block-kit-message): allow to set unfurl properties in block messages

[joscha]

WHY

Adds unfurl_media and unfurl_links options to slack send-block-kit-message action.

Background

Contrary to send-custom-message which had this functionality for a while:

pipedream/components/slack/actions/send-custom-message/send-custom-message.mjs

Lines 36 to 47 in f2ea490

	unfurl_links: {
	propDefinition: [
	common.props.slack,
	"unfurl_links",
	],
	},
	unfurl_media: {
	propDefinition: [
	common.props.slack,
	"unfurl_media",
	],
	},

currently, it is not possible to define whether to unfurl links and media in block messages or not.

This adds the two optional properties to the send-block-kit-message action.

Note: there seem to be quite a few props that are not passed through to custom actions from

pipedream/components/slack/slack.app.mjs

Line 7 in f2ea490

propDefinitions: {

- is there a specific reason for it? Otherwise we could all add them to send-message common module here:

pipedream/components/slack/actions/common/send-message.mjs

Line 7 in f2ea490

props: {

and they'd automatically inherited via

pipedream/components/slack/actions/send-block-kit-message/send-block-kit-message.mjs

Line 38 in f2ea490

...common.props,

in each of the consumers. That way all current supported options plus all future new options would automatically be supported by all slack action providers, which feels like is what we want?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
docs-v2	⬜️ Ignored (Inspect)	Visit Preview		May 20, 2024 11:43am
pipedream-docs-redirect-do-not-edit	⬜️ Ignored (Inspect)			May 20, 2024 11:43am

[pipedream-component-development]

Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified.

[pipedream-component-development]

Thanks for submitting this PR! When we review PRs, we follow the Pipedream component guidelines. If you're not familiar, here's a quick checklist:

• Create components to address specific use cases whenever possible
• Component keys should follow the format app_name_slug-slugified-component-name
• Components should follow the standard directory structure
• Prefer Node.js client libraries to REST APIs
• When making API requests, handle pagination to ensure all data / events are processed
• Use secret props to capture sensitive data
• Props and methods should be defined in app files whenever possible
• Document methods with JS Docs
• Use optional props whenever possible, and set a default value where you can
• Use async options to accept user input wherever possible

[michelle0927]

Thank you for your contribution! Looks good, ready for QA

[joscha]

Thank you for your contribution! Looks good, ready for QA

Thank you! Did you see my note? Would it make sense to pass through properties by default?

[joscha]

Thank you for your contribution! Looks good, ready for QA

And one more question: is there an easy way for me to test such changes against my pipedream workspace?

[michelle0927]

Thank you for your contribution! Looks good, ready for QA

Thank you! Did you see my note? Would it make sense to pass through properties by default?

Hi @joscha . I think it makes sense to pass through the available properties. We'll be making some updates to Slack components in the near future. @malexanderlim This is something to consider for the upcoming Slack Usability Audit.

To test changes you make to components, you can use the Pipedream CLI and pd publish actions to your workspace. They'll show up under "My Actions" when you're adding a step in the workflow.

[joscha]

Hi @joscha . I think it makes sense to pass through the available properties. We'll be making some updates to Slack components in the near future. @malexanderlim This is something to consider for the upcoming Slack Usability Audit.

After we merged this PR, I'd open another one that reuses the properties, is that okay?

To test changes you make to components, you can use the Pipedream CLI and pd publish actions to your workspace. They'll show up under "My Actions" when you're adding a step in the workflow.

Is there a special flow I can use in this component, especially because it references multiple files, etc.? The pipedream cli doesn't discover the dependency graph and uploads all needed references, does it?

[vunguyenhung]

Hi everyone, all test cases are passed! Ready for release!

Test report
https://vunguyenhung.notion.site/feat-slack-send-block-kit-message-allow-to-set-unfurl-properties-in-block-messages-12003-c26b617a60ec483e9c40c3a6f649f942

[joscha]

Hi everyone, all test cases are passed! Ready for release!

Test report
https://vunguyenhung.notion.site/feat-slack-send-block-kit-message-allow-to-set-unfurl-properties-in-block-messages-12003-c26b617a60ec483e9c40c3a6f649f942

Now I'm hungry 😋

[michelle0927]

@joscha

Hi @joscha . I think it makes sense to pass through the available properties. We'll be making some updates to Slack components in the near future. @malexanderlim This is something to consider for the upcoming Slack Usability Audit.

After we merged this PR, I'd open another one that reuses the properties, is that okay?

Yes, you can open another PR with the additional changes.

To test changes you make to components, you can use the Pipedream CLI and pd publish actions to your workspace. They'll show up under "My Actions" when you're adding a step in the workflow.

Is there a special flow I can use in this component, especially because it references multiple files, etc.? The pipedream cli doesn't discover the dependency graph and uploads all needed references, does it?

You can git clone the pipedream repo or your forked repo. Then use the pipedream CLI to publish individual actions to your workspace. Publishing the action will include any dependencies that are needed.