Full support of Slack Blocks

[miken32]

While support of Slack's Block kit is welcome, the PR in #64 for some reason implemented only a very limited subset of the available blocks and elements, and provided no easy way to manually add them. The Input block and its associated elements, as well as the checkbox and radio elements for the Action block are particularly glaring oversights.

I will likely submit a PR in the next few weeks, but wanted to file this issue just in case I'm not able to get to it.

Missing Blocks: File Input Video

Missing Elements: Checkbox group Date picker Datetime picker Email input Multi-select menus Number input Overflow menu Radio group Select menu Time picker URL input Workflow button

[driesvints]

Thanks @miken32. I'm not sure why @claudiodekker left these out. Most probably because it can potentially be quite a bit of work. Feel free to send in a PR if you like that we can review.

[claudiodekker]

Yeah, that, and the whole PR was initially simply written for internal-only use. It was only when I was done writing it that I realized it was feature complete with the V2/Webhook-based implementation, at which point I cleaned it up a little and PR'd it.

[miken32]

@driesvints are there any Laravel style guidelines beyond this section in the documentation? I've got a few style/convention questions that would ideally get cleared up before a PR is submitted.

• Looking at the code, my first thought is that I could clean up a lot of boilerplate with constructor property promotion. But I don't see much of this in Laravel; is that simply holdover from older PHP versions or is it not welcome for some reason?
• I'm going to create a base class that e.g. Illuminate\Notifications\Slack\BlockKit\Blocks\HeaderBlock will extend. Is there a preference for Illuminate\Notifications\Slack\BlockKit\Block vs Illuminate\Notifications\Slack\BlockKit\Blocks\Block?
• Similar question for traits used by classes in the Illuminate\Notifications\Slack\BlockKit\Elements namespace; Laravel convention seem to put these in a Concerns namespace? Should it be specific to the using classes (Illuminate\Notifications\Slack\BlockKit\Elements\Concerns) or is it preferred to have one place for all traits (Illuminate\Notifications\Slack\Concerns).

Sorry if these are too nitpicky, I just want to improve chances of the PR getting accepted. I've worked with large teams before and there are often a lot of unwritten rules for newcomers!

[driesvints]

Hey @miken32

• Right now we're not doing too much constructor promotion so you can just use properties for them to keep things consistent
• Illuminate\Notifications\Slack\BlockKit\Blocks\Block sounds good
• I'm not too sure about this one but I'd personally go for Illuminate\Notifications\Slack\BlockKit\Elements\Concerns if they're specific for this namespace