channels.history is deprecated, should we migrate to conversations.history instead?

[natikgadzhi]

I've just started playing around with SKWebAPI, and it seems like channelsHistory() fails since the whole family if channels* API methods is now deprecated and doesn't work for new apps already.

I'd love to work on this and port the deprecated methods from channel* to conversations*, but I'm fairly new to Swift and will need your help reviewing my PRs. Should I work on that?

[natikgadzhi]

Undo this, seems like conversations.history is already in 4.6.0, my bad.

[pvzig]

Hey Nate,

If you find something else you're interested in implementing I'd be happy to review any PRs!

Peter

[natikgadzhi]

I have a couple of things in mind — please tell me if those seem reasonable, I'd be excited to work on these! * Models are not Codable by default — not sure if that's by design or because of Codable wasn't around when you implemented them first? Possible solve for this would be to add Codable and codingKeys so that the model attributes stay consistent with the current model API, and see if the default init() can be replaced with json decoding. This could also be done in two stages: 1) add Codable consistent with the current API, 2) see if we should refactor the way we build objects. * `channelsHistory()` and `conversationsHistory()` work differently, as some other channels vs conversations methods do: channelWhatever alternative parses the response and creates model objects and then passes array / dict of model objects into the completion handler, whereas conversationWhatever just passes the response data as `[String:Any]?`, so the client can initialize their own models or SlackKit's models on their own. It would probably  be healthy to have a consistent way to work with api data across methods? What would you prefer and why? * And, obviously, since channelWhatever are depricated, should we remove them or do a compile-time warning when they're used to warn users those are going to explode? The default way they error out is — the completion handler is just never called, so no error shows up. I can repro this in a repo if you'd like. I'd be happy to file those as separate issues if you think we should discuss these with the larger community before making any plans?

[pvzig]

1. Models are not Codable by default: Yep, Codable wasn't around for the initial implementation of SKCore! Some of the models have been ported, there's a general ticket here that's referenced from a couple of previous PRs. I think tackling both the Codable conversion and object construction are worthwhile tasks. It would be great to see some more tests around our object construction as well.

2. Agreed it would be nice to standardize things. My preference is to return strongly typed objects where possible but I know it can be hard to get accurate and complete representations when dealing with a 3rd-party API which means we might be excluding properties other users might want...What are your thoughts?

3. If they just don't work, we should delete them!

I think any/all of these would be awesome improvements! If you'd like to create issues to work off of you can, but for my purposes just PRs are sufficient for 2 and 3.

[natikgadzhi]

With 3, there's a gotcha. Channel* don't work for new apps created after June or July 2020, but for apps created before that, they still work and will work until Q2 2021 I think. I'll take a look. I don't know if there's a way to fetch API capabilities (i.e. whether those methods work for a specific app / token), so it's probably too soon to delete them.

[natikgadzhi]

Thanks for the feedback! I'll go ahead and file issues, follow 1 in the general discussion, maybe propose a few models ported to Codable in a separate issue and link those.