Open gdaniel opened 3 years ago
I completely agree, now it makes more sense to return Twitter4J objects.
On the other hand, it makes it much more complex to post that data in Slack (which now is as direct as it gets). One option would be to have a cheet sheet (in wiki or readme, for example) that shows how to convert the Twitter4J objects to something that Slack can render (basically copying the formatting code that today is in the platform).
@gdaniel what are your thoughts on this?
I think it's a great idea! You can even create a Gist for it if you think it's more convenient. I'd put it in the readme, probably towards the end as an additional resource, so people don't get that in their face if they aren't actually trying to use the Twitter platform with Slack
This issue concerns the following classes:
GetTrends
LookForTweets
ReceiveDM
The
compute()
method of the classes listed above returns aList<Attachment>
representing the information they retrieve from Twitter.Attachment
is a class from the library we use to access Slack, this means that the Twitter platform is tightly coupled to the Slack platform.While this made some sense in the previous versions of Xatkit (mostly because of the limitations of the language), I don't think it is desirable right now. We should decouple the Twitter platform from the Slack one, and let bot designers create any kind of bot interacting with Twitter.
The solution I see is to remove the mapping logic from Twitter4j classes to attachments. For example the compute method in
GetTrends
could be updated as follows:(This is just an example, it may make sense to directly return the
Trends
instance instead of creating a list).With this kind of implementation bot designers can call this action in any context (Slack or not). Of course this also means that formatting Twitter4j classes to attachments is not done automatically anymore. I think it's fine, and we can provide some formatters later.