Feature request: Ability to see formatted/rendered preview

[aaronsteers]

💡 The Idea

We use this library a bunch to deliver Slack messages. However, formatting is always tricky and we often get formatting rules wrong a few times before getting it right. Any interest in a "test", "preview" or "render" interface that would (in our case), render a preview of the Slack message in markdown or html or similar?

🔨 Breaking Feature

Nothing breaking.

❗ Hard Part

Goes without saying that supporting n preview engines could get unwieldy. Perhaps those could be added as their own targets? Like slack-html-preview could be a separate engine to use when wanting a preview of what slack would deliver.

Other solutions might be available - just wanted to put the idea out there and see if it's interesting and/or possible.

[caronc]

The problem is that the rendering takes place on the Slack server. You can use the cli tool with -vvvv to increase verbosity. You'll see everything sent to Slack then. That said, it isn't a preview like you're asking.

Would you want the contents to be dumped to stdout? Are you using the cli tool?

[aaronsteers]

@caronc - We are using the Apprise python client, in the target-apprise wrapper for EL data pipelines. (Code here.)

Since I couldn't find any reference to this capability even in the Python Slack client, I opened this related issue:

• Ability to render previews of message/post content as html or similar. slackapi/python-slack-sdk#1323

[aaronsteers]

Perhaps the best solution (for now at least) is to send messages to a dummy Slack channel. 🤷 There's a Block Kit Builder tool, but I didn't see similar capability in the SDK itself, and I don't know how we'd integrate with that web-based tool.

The only other approach I can think of would be to start with vanilla Markdown and come up with a pre-processor to convert from the markdown into Slack-favored markup blocks. That's also not a trivial effort though. 😅

[caronc]

It just seems like a lot of effort for one service of the 85+ supported. Every upstream service renders stuff differently. It's use case only seems only seems useful for initial message preparing which like you said could go into it's own empty channel.

I can see a use case where just the payload is printed or captured to stdout or a variable (if using the library) so you could see a MARKDOWN to HTML conversion (or vs versa) take place. But even that is something only used for debugging and it's already part of the Apprise unit tests to capture the edge cases during this conversion.

Sorry to write so much, I'm just thinking aloud in case you or others have a comment. But I'm not sure if this request is really ideal at this point. Thoughts?