SlackNextGenerationの開発を触って学んだこと振り返り

# この記事について
社内向けPJで、Slack NextGenerationを触ることになったので、
学んだことの整理、自身の振り返りのため、まとめてきます。

細かい仕様などは公式ドキュメントがあるので、ここでは触るまで理解できなかった部分 or いまだに少し曖昧な部分を中心に振り返っていきます。

# SlackNextGenerationのふりかえり

## 開始するにあたりやった方がいいこと
- チュートリアルみる。

初見者は必須。流れを理解するのは一番手っ取り早く、簡単。

https://api.slack.com/tutorials/

- ドキュメント読む
公式ドキュメント。ちょっとサイト構成がわかりにくいが難点。
正直見づらいので、チュートリアルでやって、補足で読むがおすすめ。

https://api.slack.com/docs

- slack開発者の記事など見る
色々参考アイデアがたくさん公開されているので、参考になります。
以下はSlackのアドベントカレンダー2022版。

https://qiita.com/advent-calendar/2022/slack

## アプリケーションの構成について

以下の様な階層構造になっている。
（基本的な場合。アプリケーションによっては異なるケースもあると思います。）

<構造イメージ>
上から親階層 -> 子階層
- trigger
    - workflow
        - function

### triggerとは？
エントリーポイント。大きく以下の種類がある。

- webhook: 外部連携したい時に使われる。外部から使用できるWebhookURLが生成される。
- ワークフロー: Slack上で使用したい時に使われる。SlackのUIかクリックなどで起動できる。

ユーザIFだと思うとわかりやすい。
triggerが起動すると、内部で定義したworkflowが呼び出される。

### workflowとは？
実行される処理の一覧が定義される。
MVCでいうとこのC。

各処理でfunctionを呼び出す。

### functionとは？
名前の通り、単体機能。
ここでメッセージをPOSTしたり、ユーザにアクションしたりなど、実際に動作する細かい動作をコーディングしていく。

処理の結果はworkflowに返却することで、workflow側で判定処理を行うことができる。

## denoについて

https://deno.com/

実行環境はdenoが使われてます。
でも実際にユーザがdenoを起動させたりすることは、ほとんどないと思います。（自分も今のところ一回もない）
理由は後述の動作検証にて。

なので、意識するのはコーディング時だけ。
denoのAPIを使用するときや、ライブラリをインポートする時は、denoの記述ルールに則って行う必要があります。

## 動作検証について

Slack開発で一番理解が難しいと感じたのが動作検証なので、整理しておく。

ローカルで動作検証する時は、 `deno run` 使いたくなる（使うイメージある）けど、実際は使わない。
使うのは `slack run`。

slack runすると、コーディングした内容がslack platform上に展開され、一時的にslack上で使用できる状態となる。
（インスタンスApplicationがデプロイされるイメージなのかな？）

そのインスタンスAppを使用したいworkspaceと紐づけて、動作をさせることで動作を検証することができる。

triggerのタイプによって検証フローが少し異なる。

### workflowの場合

コーディングした後、`slack run`すると専用のワークフロー起動用URLが発行される。
そのURLを起動したいチャンネルに投稿すれば、インスタンスAppのワークフローが起動する。

デバッグログなども`slack run`したターミナルに表示されるので、動作確認も簡単。
`console.log`もコンソールに表示されるので、denoの感覚でデバッグできる。

また、起動中にコードの内容を変更した場合も即時に反映される。便利。

### webhookの場合

こちらはworkflowに比べ少し特殊。
slack上に展開されてる領域に随時アップロードが必要。アップロードしない場合、ローカルの変更が反映されない。

1. (初回のみ) `slack trigger create` でTriggerをSlackプラットフォーム上に作成
1. コードを変更する
1. `slack trigger update --trigger-id {トリガーID}` を実行し、差分を反映させる

検証用アプリは本番アプリとは別に生成されるので、それぞれ承認が必要。

## デプロイについて

コーディング、検証が終えたらいざデプロイへ。
デプロイは`slack deploy`を使用することで行える。
権限をもたないユーザの場合、管理者にDeploy申請を行う必要がある。
以下の様なエラーがでる。

```
Admin Approval is required on this workspace. Alternatively, you can try installing it on a test workspace with App Approval turned off.
? Would you like to send a request to the workspace admin for approval to install this app? Yes
? Please enter a reason for requesting this app:  {管理者に申請するデプロイ理由を記述する}
Your request to install the app is pending.
```

オーナーが申請を承認後、再度 `slack deploy`を実行すると、Deployが実行される。

```
🎁 App packaged and ready to deploy
   0.038MB was packaged in 3.9s

🚀 daily-report deployed in 8.3s
   Dashboard:  https://slack.com/apps/XXXXXXXX
   App Owner:  YYYYYYYY
   Workspace:  ZZZZZZZZ

🌩  Visit your workspace to try out your live app!
   When you make any changes, update your app by re-running slack deploy

💌 We would love to know how things are going
   Survey your development experience with slack feedback
```

## 余談

### 組織内で検証用アプリを使用したい場合

初回の起動時に対象のworkspaceに検証アプリをインストールする必要がある。
その際には組織の管理者に検証アプリのインストールを承認してもらう必要がある。

---

以上、ざっくり整理。
まだまだ理解が曖昧＆できてないとこが多いので、
定期的アウトプットして、理解を深めていきたいです。

なにはともあれ、Slackはめっちゃ便利なので、Appと仲良くなって生産性あげてきましょー。 :tada: