本記事は Vueのカレンダー | Advent Calendar 2022 - Qiita の17日目の記事です。
まぁポエムみたいな記事なんですが。
Vue3 とComposition API
Vue3にComposition APIという新しいコンポーネントのインターフェースが登場しました。
これにより、コードをピュアなJSとして扱うことができ、型付がより便利になったりコードの分割を可能にします。
で、あなたにComposition APIは必要なのか
「せっかくVue3に挑戦するんだし、Composition APIで書きたいよね〜」と思っているみなさん、9割くらいはその必要はないと私は思っています。
なぜなら、「CompositionAPIでできることは基本的に増えない」「（コードベースが大きくならない限りは）一つのファイルにあるほうがまとまってて見やすい」「というかrefとかreactiveとか認知負荷が大きい」というものです。
Composition APIを使う必要があるのは、コードが大きくて見づらいんじゃい！とか整理したくなったとか、コンポーネントのロジックを再利用したくなったときだけで十分でしょう。
Composition APIでやってみたけどよくわかんねー！ハマった！もう嫌だ！ってなる前に、Options APIで書き直してみるという選択肢を忘れないでください。
Options APIのほうが歴史的にドキュメントも多く、公式ドキュメントでもその多くのページをOptions APIに割かれています。
むしろ、Composition APIのほうは「これを使おうとしてるあなたにならこれくらいで十分でしょ」くらいのドキュメントしか割かれていません。
Composition APIとOptionsAPIとの区別はつくようにする必要がある
インターネット上の記事という資産は是非活用していきたいですよね。
ところが、Vue3の登場とともに書き方がComposition APIとOptions APIのものとで混在するようになりました。
これによって、「自分が読んでいる記事はどちらのAPIで書かれているのか」「自分のプロジェクトならどう書けばいいのか」を意識する必要があります。
-
<script setup>から始まっている → Composition API - setup() メソッドがあり、その中にかかれている → Compotision API
- refとかreactive とかがでてくる → Composition API
setup()メソッドの中でreturn されたメソッドは、 methods 配下に置かれたのと同様に振る舞います。
ref, reactive は data() 配下に置かれたのと概ね同様に振る舞います。computed も同様。
watch, watchEffect はsetup() メソッド内で呼べば（returnしなくても）watch配下に置いたのと同様に振る舞います。
setup()メソッド内で実行したロジックはmounted 相当で呼ばれます。他のライフサイクルは対応するメソッドの中のものがいい感じにマージされます。
ぐらい？ですかね。
コーディングルールとしてのComposition APIとOptions APIについて
複数人でVueを書くということもあるかもしれません。
その場合、コーディングルールとしてComposition API（またはOptions API）を強制するかという問題に直面することがあります。
これは難しい問題で、難しいです（ぐるぐる目
結論的なもの
オチをなにも書いてなかったのでモヤっとした記事だったので追記。
あなたがフロントエンドに初めて挑戦するならComposition APIは必要ないでしょう。
また、Vue2は経験が十分にあったとしても、今のコードの複雑性に課題感を抱えていなければ必要ないでしょう。
やってみた系の記事でComposition APIで書かれているものがたくさんでてくるのははしかにかかってると思っていいと思います。
Composition APIを使いこなすには、センスや経験といったものが必要となります。
ReactでHooksの経験があるなら似たような感覚で使えると思います。
今のコードを保守するのは限界だ！ここにComposition APIがハマりそうだぞ？そう思ったときにあなたの強力な武器になってくれるでしょう。