Context
All post_* methods (post_ok, post_warning, post_error, post_info, post_start, post_end) use the Slack attachments format to render colored messages.
Slack has classified attachments as legacy since 2019 and recommends Block Kit for new development. While attachments still work, they receive no new features and may eventually be deprecated.
Current behavior
All colored methods build this structure:
{
"attachments": [{
"color": "#2eb886",
"text": "message",
"mrkdwn_in": ["text", "title"]
}]
}
Block Kit equivalent
The same message in Block Kit would look like:
{
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "message"
}
}
]
}
Note: Block Kit doesn't have a direct equivalent for the colored sidebar that attachments provide. The visual equivalent requires a different approach (e.g., emoji prefixes, dividers, or context blocks).
Options
-
Add Block Kit as an alternative output mode — e.g., Slack::WebHook->new(format => 'blocks') while keeping attachments as default for backward compatibility.
-
Hybrid approach — keep post_ok/etc. using attachments (since colored sidebars are their whole point), but add new block_* methods for Block Kit.
-
Accept the status quo — attachments work fine for this module's use case (simple colored notifications). Block Kit adds complexity without clear benefit for the preset-layout pattern.
-
Deprecation notice — add a note in the POD that attachments are legacy, and point users to post() for custom Block Kit payloads.
Recommendation
Option 4 (documentation) is probably the right immediate step. The module's value proposition is simple colored notifications, which attachments handle perfectly. Block Kit is more powerful but also more verbose — it doesn't align with the "preset layout" philosophy.
The post() method already supports arbitrary hash payloads, so users who need Block Kit can use it today:
$hook->post({
blocks => [{
type => "section",
text => { type => "mrkdwn", text => "Custom Block Kit message" }
}]
});
🤖 Created by Kōan from autonomous analysis session
Context
All
post_*methods (post_ok,post_warning,post_error,post_info,post_start,post_end) use the Slack attachments format to render colored messages.Slack has classified attachments as legacy since 2019 and recommends Block Kit for new development. While attachments still work, they receive no new features and may eventually be deprecated.
Current behavior
All colored methods build this structure:
{ "attachments": [{ "color": "#2eb886", "text": "message", "mrkdwn_in": ["text", "title"] }] }Block Kit equivalent
The same message in Block Kit would look like:
{ "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "message" } } ] }Note: Block Kit doesn't have a direct equivalent for the colored sidebar that attachments provide. The visual equivalent requires a different approach (e.g., emoji prefixes, dividers, or context blocks).
Options
Add Block Kit as an alternative output mode — e.g.,
Slack::WebHook->new(format => 'blocks')while keeping attachments as default for backward compatibility.Hybrid approach — keep
post_ok/etc. using attachments (since colored sidebars are their whole point), but add newblock_*methods for Block Kit.Accept the status quo — attachments work fine for this module's use case (simple colored notifications). Block Kit adds complexity without clear benefit for the preset-layout pattern.
Deprecation notice — add a note in the POD that attachments are legacy, and point users to
post()for custom Block Kit payloads.Recommendation
Option 4 (documentation) is probably the right immediate step. The module's value proposition is simple colored notifications, which attachments handle perfectly. Block Kit is more powerful but also more verbose — it doesn't align with the "preset layout" philosophy.
The
post()method already supports arbitrary hash payloads, so users who need Block Kit can use it today:🤖 Created by Kōan from autonomous analysis session