jusleg / slackify Goto Github PK

I've added the RepeatHandler as documented here but (on Rails 7 at least) this gives an exception: repeat_handler is not defined (Slackify::Exceptions::InvalidHandler) ... in 'constantize': uninitialized constant RepeatHandler (NameError).

This is because the Slackify.configure call in config/initializers/slackify.rb is attempting to register the handlers, but they have not been loaded by Rails' autoloader yet.

After reading these docs, I tried using Rails.application.config.to_prepare in config/initializers/slackify.rb:

Rails.application.config.to_prepare do
  Slackify.configure do |config|
    config.slack_bot_token = ...
    config.slack_secret_token = ...
  end
end

This stops the exception on startup, but any changes to the handlers are not loaded until you manually reset the server.

I've also tried adding config.autoload_once_paths << "#{root}/app/handlers" to config/application.rb and again it fixes the startup error but changes to handlers are not loaded without manually resetting.

Instead of having a regex with all the parameters being ordered, we should also support named parameters so that we can reorder the parameters. We would still have a regex for the action matching, but then we also make sure that the arguments are there and of the proper type before calling the command.

https://gist.github.com/yoshrote/f24f84c1e010a1296f1178849ef5ef34

Ran into issue when calling chat_unfurl Slack API method where the payload for unfurls: doesn't accept callback_id in the JSON. Resulting error: WARN: Slack::Web::Api::Errors::CannotParseAttachment: cannot_parse_attachment

From Slack support: Unfortunately, that[chat_unfurl] method doesn't support the use of callback_id
Slack support informs me that we should instead be looking for block_id or action_id for the interactive callback for that method.

When running in development, we encounter a lot of DEPRECATION WARNING: Initialization autoloaded the constants [...]

Slack recently made public the block kit for richer attachments. This new UI framework doesn't make use of callback_id and favors unique action_id per button/interactive field. I believe we could introduce compatibility in the framework by making those action_id work like a callback_id. We currently have the following format in the callback_id: handler_name#method_name. This won't work with the block components as two buttons could have the same action_id.

I believe this could be fixed by appending extra stuff to the action id just to make it unique and pass slack's payload verification. For instance, we could have a simple counter after the method name. This would ensure uniqueness and we will just not take into account the counter value when parsing.

Example

button1_action_id = my_handler#my_method#1

button2_action_id = my_handler#my_method#2

Then we run something like:

action_id.split('#').tap |parsed_action_id|
  handler = parsed_action_id.first
  method = parsed_action_id.second
end

The counter could be introduced in a wrapper for the attachments. We send non slack approved block attachments (blocks having duplicate action id) and we make them valid by adding the counter to it. Hardcoded attachments will not need to use the wrapper, but on the fly attachments could make use of it.

Questions left to be answered before going forward

• Does slack send the original attachments in the event API payload?

• What's the difference between a regular interactive event vs a block event in a callback?

• Did slack introduce a new interaction type in their callback API? (It would make our lives way easier if they did

Is slack-ruby-client ready to handle block payloads?
Yes, it is 😄

Can we still edit/delete messages the same way (3-second reply window, response URL for 30 min and channel + ts for any time)?
No, the response url is the only way of doing it right now. Perhaps a good way would be to add a method in which you pass a response url and a new payload to make the code look similar to the previous behaviour

TL;DR

Use the action_id as if it was a callback_id to trick slack into sending our old payload logic into the fancy new block attachments. It would be cool 😄