Introducing Slack.NetStandard

I'm a sucker for a good RPG game. Back in the day it was Baldur's Gate, these days it's Witcher 3 or Skyrim. I love the format. You have a story - it's a really good story - and you're told to wander off in that direction to learn more.

I look left. I look right. I see the path clearly laid out for me....aaaaand I wander off along the grass and through the trees to see what I can see. Then I come across a house and someone's lost their family heirloom and it was going to pay for them to eat for the next year and could I find it oh dear adventurer.

Hell yes - because I love me a side quest!

Turns out, this isn't just with games. I have an idea that's been kicking around for a while now - and I decided that because I'm not great with the visuals I'd try and build the initial interface using Slack's Block Kit framework. I'm a .NET developer at heart and this has all been around for a long time so I nip into NuGet and look for a package that does the trick. Although there's varying support nothing that seems to be up to date enough (by that I mean covers the Events API that new apps have to use).

Go to the Slack community page and there we have a dead end too.

Now of course I could walk the path and continue the main quest like good adventurer. But I'm a sucker for the side quest! So I crack open Visual Studio and start coding. Aaaaand - so yeah, that was a few weeks ago now. And I have a new NuGet package!

Say hello to Slack.NetStandard

This side quest was a beast. The documentation for Slack APIs is overall really good - and there's a lot to implement if you're trying to be complete. But you can see where the APIs have gone through a lot of maturity and the documentation just hasn't kept up. Thankfully my work with the Alexa libraries meant I was pretty used to it, and almost all of the big stuff was there in incredible detail.

Once again trying to write tools for a strongly typed language came up against problems with the "yeah it's just kind of whatever type it needs to be" attitude of the dynamic languages underpinning these APIs. Channels being both string and object depending on the context meant some re-working when that kicked in late in the day. To be clear - these aren't difficult problems technically, these are tooling specific problems where consistency is key for usage. The last thing you want is a confused user because your types don't match in one property out of ten.

But I loved it, I went v1 two days ago and as is my want for most of these things it's all open source. Hundreds of classes and tests later and now I'm back to the main quest to see how that story unfolds.

Let's find out!