Proposal - add threading & reactions to Slack

[xeger]

This isn't finished; think of it more as a proposal, which we'll be happy to clean up if you like the idea.

Our goal is to let our bot use some advanced Slack features, namely:

• replying to threaded messages in the same thread where they appeared
• starting a new thread to reply to some messages
• replying with an emoji reaction in addition to, or instead of, a chat message

We wanted to do all three of these things without modifying the Lita core. To accomplish that, we added a SlackSource which subclasses Lita::Source and adds Slack extensions; when the Slack adapter processes messages, it instantiates SlackSource so that when its own methods are called back, it can rely on the extra state tucked away inside the source. (Naturally, it gracefully degrades if you pass a vanilla Source into the adapter.)

The adapter itself has gotten some new, Slack-specific methods to react_with_emoji, reply_in_thread, and so forth. However, all of these are obscured from the bot's handlers. Instead, we have introduced two new conventions inside the adapter's send_messages, since this is the "nexus" of message sending which allows our conventions to apply to all of the ways that Lita has to send messages.

The two conventions are:

• Sending a Symbol instead of String message, causes an emoji reaction to the source.
• Any message beginning with the Unicode ellipses character … is sent in a thread of the original message (i.e. it begins a new thread even if the original message was top-level)

In addition, because SlackSource tracks threadiness, any reply to a threaded SlackSource will be made in the same thread.

We're interested in your feedback on the way we have implemented these things, and happy to clean up our implementation and add tests once we've heard your thoughts. My own observations:

1. It seems a bit weird to incorporate notions of "thread" and "reaction" into Lita's core, so the use of message-formatting conventions is probably a good idea, to keep the core adapter-agnostic. Both of these conventions work sensibly when used with adapters that don't support them.

2. It seems dirty that we need to use a special SlackSource to track extensions. If the Source class kept track of extensions, or pointed to the original Message, we could get rid of the subclass.

[xeger]

Tagging @crunis since he contributed

[xeger]

Closed due to disinterest/dormancy.

[spkane]

This fork has solid support for threading https://github.com/Shopify/lita-slack