【第二十九天】硬上也是出來！但看了就煩躁！

原本以為昨天會很輕鬆簡單，但卻卡的像在演127個小時！
雖然寫出來了，但因為夜深開始急躁，直接改master不做PR了（絕對會讓隔一天的自己後悔的事情），
所以，今天就來心平氣和的把這些該死的毛梳理一遍吧！

整理了幾點目前硬幹後讓人討厭的地方！

為了方便，我們把payload直接硬塞進replySlashCommand

public function replySlashCommand(string $text, SlackMember $operator): array
{
    $command = explode(' ', $text);
    $action = $command[0];
}
// 被改成

public function replySlashCommand(string $text, SlackMember $operator, array $payload = []): array
{
    $command = explode(' ', $text);
    $command['payload'] = $payload;
    $action = $command[0];
}

原本的$command就已經夠讓人毛燥了，現在還硬是加上了一塊payload...
看起來就是很不順眼！
但到底是怎樣個不順眼咧？仔細想想到底當初為何會決定就這樣硬塞進去。以及這樣做真的好嗎？

原本情境是打算做成分頁，當初原本以為會是共用API，所以選擇寫在同一個function內（合理）
且分頁的操作除了頁數不同，程式執行的內容其實是相同的（合理）

但現在情境是，所有的互動窗口都是由另外一隻新做的API去接，
也就是說將來不論是切分頁、Redirect或是之後更多其他應用時，還擠在同一個function就會很shit！
所以勢必得斷開魂結！斷開那一切的牽連！

首先我們要知道，我們是透過callback_id來讓API去認得原始的訊息是什麼的，
並非正規解法但我分享一下我的做法是把指令<空格>Service::class組在一起做為callback_id。
唯一要注意的就是callback_id長度不可超過200
舉例：/twitch list傳過去的格式如下

{
    ...略
    'callback_id' => 'list App\Services\TwitchService'
    ...略
}

如果之前有做好的話，這樣我們就可以判斷出它的originalMessage是誰了！

補個PR
這樣就算InteractiveSlashCommand多複雜，也都僅限於SlashCommands這層！
也方便以不同的Class做為回應

    public function replyInteractiveSlashCommand(array $payload, SlackMember $operator): array
    {
        $command = explode(' ', $payload['callback_id']);
        $command['payload'] = $payload;
        $action = array_first($command);

        $actions = [
            'list' => TwitchList::class,
            // 例如以下範例
            'delete' => ConfirmDialog::class,
        ];
        $instance = array_get($actions, $action, TwitchDefault::class);

        return Helper::toSlashCommand($instance, $command, $operator);
    }

雖然最後照著想像中的分頁完成了，但實際用起來還是覺得不好用ＲＲＲＲＲ
或許要再找個更好的方法，例如Filter...再來玩看看唄！