はじめまして
都内で WEB 開発をしています。今は主に Vue を書いてます。
現在、私の所属するフロントエンドチームでは、Vue 2 系 + TypeScript をつかって開発しています。
当然、これまでは (いわゆる) Options API によってコンポーネントのコードを記述していたのですが、数ヶ月前くらいから「これからは基本的に Composition API をつかっていこうぜ！」という方針になりました。
「Composition API をつかっていこうぜ！」というのはイイけど、Composition API をつかうメリットが何なのか、モチベーションはどこにあるのか・・・。そういった本質的な価値がイマイチよく分からないまま、実装者が Reactivity を強く意識する、新しいコーディングスタイルの世界に足を踏み入れました。
Composition API をつかい始めると、世界が一気に変わります。
以降でも触れますが、TypeScript が活躍できるようになったおかげで、Vue の Composable な機能や、サードパーティライブラリ、とくに Vue Apollo (GraphQL クライアント) まわりの型の複雑さにヒーヒー言ってました。
それ以外にも、Reactivity が意図せずに途切れたり、vue の composable な機能を setup() の call の外でつかおうとすると怒られたり。
ハマりポイントな Composition API のクセはたくさんあります。
ですが、最近はちょっと慣れてきて、「あー、なるほどね」と思うことも増えてきました。
そんな最近の私の「あー、なるほどね」ポイントをご紹介します。
(具体的なコードとかは載せてません。文章だけ)
あー、なるほどね
1. template で利用している変数が追いやすくなる
Compostion API を利用すると、「あれ、この変数 (option のプロパティ) って、修正したら描画に影響あるかな？」というのが格段に減ります。(以降は option のプロパティのことも変数と呼びます)
なぜなら、Compostion API では、template で用いられる変数は setup() の戻り値でないといけないからです。
Options API は、data、method、computed などのプロパティが、全て template から参照可能なため、注意深く template を読み直さなければ描画に直接的に関わる変数を特定できません。
小さなコンポーネントではとくに問題はありませんが、大規模なコンポーネントでは "改修" が新たなバグを産む潜在的リスクを抱えていました。
これに比べ、本項の冒頭でも触れたように、Compostion API では「template で用いられる変数は setup() の戻り値でなければならない」という制約があるため、裏を返せば setup() の return を見ればどの変数が描画に使われているかが一目で分かるということになります。
また、処理を追う際も、return から辿っていけばいいので、コードを読解する時間も短縮できると思います。
2. 処理の分割・カプセル化・共通化・外部化がしやすくなる
Options API では、「data は data、method は method、computed は computed」というように、それぞれのセクションに定義しなければいけませんでした。
そのため、処理の流れを追う際に、「この data は この method でつかわれてて、しかもそれは computed で変換されてて・・・。」とコードの中をあっちゃこっちゃ駆け回っていました。
Composition API では、そうした制約はないので、関連した文脈を持った処理をひとまとまりにすることができます。
「処理をひとまとまりにすることができる」ということは、それらをクロージャに閉じ込めて、"状態" を隠蔽することもできますし、そうなれば当然カプセル化もしやすくなります。
さらに、Composition API では「全てが this に所属する」といった世界観から解放されるため、最小限の処理は Pure な関数にするモチベーションも高まります。
「Pure な関数にするモチベーションが高まる」ということは、頻出処理を共通化したり外部化することへの心理的なコストも下がり、再利用性の高いコードが産まれやすくなる ということにも繋がるかと思います。
3. TypeScript のパワーが発揮される
Composition API をつかう最大のメリットの一つです。
個人的には 2. 処理の分割・カプセル化・共通化・外部化がしやすくなる もけっこー重要だと感じていますが、やはりココを「最大のメリット」として捉える方は多いと思います。
Composition API をつかうと、とにかく TypeScript が活躍してくれます。
Composition API をつかうと、「変数名の変更漏れてて動かなくなってたわ！バグです！」ということがなくなります。
なぜなら TypeScript が仕事をしてくれるからです。
Composition API をつかうと、「API レスポンスを格納してた変数の構造体が変わってたわ！バグです！」ということがなくなります。
なぜなら TypeScript が仕事をしてくれるからです。
Composition API をつかうと、「この変数の中身なんだったか分かんねえしコード追うのも面倒くさいし変数名的にも
Boolean やろ。と思ってたら String でした！バグです！」ということがなくなります。
なぜなら TypeScript が仕事をしてくれるからです。
TypeScript を適切につかっていれば、TypeScript がめちゃくちゃ仕事してくれます。
TypeScript を適切につかうために学習コストもランニングコストもかかりますが、同じようにコードの信頼性を高めるために単体テスト書くことを考えたらカワイイものではないかと思います。
あと、TypeScript 慣れておくと型に厳格な言語を新しく学ぶ際の障壁も下がります。
そんな感じです
これを読んで下さった "Composition API コワイ" 勢の皆さんも、Composition API に畏れず立ち向かっていけば、いつか「あー、なるほどね」となる日が来るんじゃないかなと思います。保証はしないけど。
おしまい。