Composition Function の切り出し方のパターンまとめ記事を読んだ

なぜか Chrome 拡張の create link が壊れたので URL 直貼り(どうやら自分だけでなくみんなも壊れたと言ってるっぽい)

Composition API において、ロジックの切り出し方については十人十色というか、ほんとに個人ごとに色々な意見があると思う。

今回は切り出したロジックをどう配置するかではなく、「そもそも切り出すロジック/切り出さないロジックをどう決めるか」という感じの話だった。

記事で出されていたパターンは、

切り出さない(ロジックをすべてコンポーネントに書く)
- ロジックを切り出すことでシンプルに視認性が悪化する
- ただしコンポーネントが複雑になるとコンポーネントファイルが肥大化する
コンポーネント自身の責務とそれ以外に分ける
- 見た目と、その見た目と関係するイベントのハンドリング、そしてその結果の見た目の処理のみをコンポーネントに持たせる
- どのみち視認性は下がる
副作用のあるものとないものに分ける
- 副作用 => 評価値を得ること(関数では「引数を受け取り値を返す」こと)以外の処理
- その関数を呼び出すことで state を変化させたりするものはだいたい副作用に当たりそう
- 視認性はそこまで悪くなさそう
- 副作用のあるロジックのテストがしやすそう
共通化/再利用できるものとできないものに分ける
- 共通化して別の箇所でも使えそうなロジックは切り出す
- 個人的にこれは「共通化/再利用できる」の基準が曖昧になりそうな予感がしているけどどうだろう
全部切り出す
- ロジックを完全に分離する
- コンポーネントの責務とそれ以外に完全に分離できる
- ただしコンポーネントに複数の責務を負わせることもできそう

という感じ。

Composition API をフル活用するのであれば完全に切り出してしまってもよさそうな気がするが、たとえばそのコンポーネントでしか使わない local な state を切り出す必要はあるか……？切り出すとしたらどのように切り出すか？という疑問が出てくる。

どのパターンが自分にとって/チームにとって最適かを正しく考えて、正しい運用ができるようにしないといけないなあ……。