【Vue3に備える】実務で使うComposition APIについて考える

slont
slont
Mar 11 · 18 min read

◆はじめに

どうもこんにちは。Vueが好きすぎて社内でVueを布教している@_slontです。
今回のテックブログでは、これからリリースされる待望のVue 3を万全の体制で迎えるべく、新機能の中でも個人的にアツいと思っているComposition APIについての考察をしたいと思います。

Composition APIは一体僕たちにどんな驚きをプレゼントしてくれるのか。それを確かめるために我々はアマゾンの奥地へとむk(ry



さて、近々リリース予定のVue 3は、パフォーマンス改善の他、Composition API, Fragment, Portal, Suspenceなど様々な新機能があります。

その中でも、大規模プロジェクトに弱いと言われていたVueの銀の弾丸として(?)、ユーザが待ち望んだComposition APIが、2系のプラグイン@vue/composition-apiとして先取りできるということで、僕の担当するプロジェクトでも人柱として利用しています。

今回はこのComposition APIを実際に使ってみて感じる、メリット・デメリットや実務での使い所を考察してみようと思います。

免責になりますが、これはあくまで個人的な考察であり、Vueやステークホルダーの思想を汲み取った実装方針ではない可能性もあることをご了承ください。


◆対象

この記事の対象は

  • Composition APIを検討している
  • Composition APIプラグインを導入して触り始めている

といった方です。

という方は、前述したkazuponさんのスライド(まもなくやってくる Vue.js 3)で、Vue 3の素敵機能に目を通すと良いと思います。


◆ 実装例

早速ですが、イメージを掴んでもらうために、実装例の一部を紹介します。実際に使っている中でもよくある、データ配列をフェッチして、テーブルで表現するといった画面です。

今回使った例のリポジトリは以下に上げてあります

また、Composition API Ver.で利用している各種モジュールの詳細は、この記事の後半に載せています。

イメージ

これはよくあるテーブルでのデータ表示と、左にあるチェックボックスでの実装です。

今回は選択状態を管理するためのTableModuleと、データ管理をするItemModuleで実装しました。
非常に簡潔で、切り出す必要があるかを疑問に思いますが、たかがテーブルと言えども、各ページで多種多様なフィルタや検索機能を設けると、このレベルのコードでも重複して肥大化しがちなのがVueなのです。

ソースコード

Vue Syntax Ver.(従来の書き方)

/VueSyntax.vue

Class Based Componentでは無く、Vue.extendによる実装です。こちらは生のVueに近い書き方が可能なので、僕はこっちの方が好きです。

中身は普通なのですが、こうして見ると、テーブル操作とデータ操作の変数・関数がごちゃ混ぜになっていることがわかるかと思います。

このレベルのコンポーネントでこれなので、これ以上複雑な画面だと如何にscript部が肥大化するかは想像に難くありません。

Composition API Ver.

さて、Composition APIでの実装も見てみましょう。

CompositionApi.vue

template部こそ一緒ですが、かなりすっきりしましたね。
ぱっと見て、テーブルに関するモジュールと、Itemに関するモジュールで分かれているのがわかります。
ItemModulectxという変数を引数にしていますが、これこそがVueにおけるコンテキストそのもので、こいつを引き回すことで、例えばemit$router$storeなどに関する処理も外部に切り出すことが可能です。


◆Composition APIを利用するにあたって

まずこのComposition APIは、以下に該当する人には取っ付きづらく感じるかなと思います。

  • サーバサイドの経験がない
  • 小中規模のフロントしか経験がない(〜十数ページ程度の画面しかないSPAなど)
  • VueやReact、AngularのView層(HTML、テンプレート、スタイル)しか触れる機会がない

これは、Composition APIが解決する問題が、いわゆるモデル層、ないしビジネスロジックに関連することが多いと推測されるからです。

そもそもフロントにとって、このレイヤーの処理のほとんどはサーバサイドに隠蔽され、JSON色付け係よろしく、ある程度の規模では無視しても問題ないものです。

しかしながら、プロダクト次第では、ビジネスロジックもある程度フロントに内包せざるを得ない場合があります。僕が所属する金融ドメインも、その一例かと思います。

そういったプロダクトの背景や、メンバーのスキルセットによって、Composition APIを採用するかを検討するべきかなと思います。

  • デザインパターンに詳しい人や、(クリーン)アーキテクチャに強い人が、メンバーに居ない
  • 高々10ページ程度しかない簡素なアプリである
  • コンポーネント間での重複ロジックがあまりない
  • 複雑なロジック持つメソッドを持たない、コンポーネントが持つプロパティが多くない
  • Vueのシンタックスでしかコードを書いたことがない
  • Vueのthisやコンテキストがなんなのか良くわかってない

もちろん、単なる技術的興味などでの採用も考えられますが、Vueのシンタックスは、あれはあれで非常に良いものです。
無理にメンバーの学習コストを上げて新機能を取り込む必要もないので、十分検討しましょう。


◆大規模Vue開発の問題点

以下からはTypeScriptでの開発を前提とします。
Vueの大規模開発では、度々以下が問題になると思います。

  • this (VueComponent) のコンテキストを巻き込んだロジックを切り出しづらい
  • 重複したロジックが、各種コンポーネントに存在する
  • 重複したロジックを、タイプセーフで再利用しづらい
  • コンポーネントのscript部が肥大化、可読性の低下
  • data, computed, methodsを、ロジック毎にまとめられない
  • template部で利用するプロパティのみにスコープを切れない(切りづらい)

Composition APIは、これらの問題を解決するのに比較的適しています。
特に、型推論を十分に使えるようになることは大きなメリットです。


Composition APIのメリット

これはもちろん、前述の課題を解決できることが大きなメリットですが、特には

  • 型推論を十分に使えるようになる
  • コンテキスト(this)を巻き込んだロジックを切り出しできる
  • 再利用性が高まり、コードが圧縮できる
  • (しっかりとした設計ができれば)可読性が高まる
  • ViewModelとModelを分離できる→実装担当を分割できる

あたりかなと思います。

特に、thisのコンテキストがなくなり、関数的に利用できるようになったことで、Vueのコンテキストを利用したロジックもタイプセーフに切り出すことができるようになったのは、非常に便利だと感じました。

Composition APIのデメリット

  • プログラミング力が試される

Composition APIは、Vueの暗黙的なコンテキストを取っ払った代わりに、そこを意識したプログラミングが必要になります。
つまり、今まで書いていた「Vueだから動く」コードではなく「ここまではロジックで、ここからはVueの世界」ということを、きちんと理解して書く必要があるため、少なからずプログラミング力が問われると思います。

余談ですが、Vueの素晴らしいところは、こういったプログラミング特有の煩わしさを隠蔽して、デザイナ含め、ある程度の初学者でも書けるようなところだと、個人的には思っています。

  • より、設計が重要になる

ありがちな話ですが、ロジックが重複しているからといって、何でもかんでも共通化するわけにはいきません。

を常に意識しなければ、切り出した後に、それぞれの箇所で細かな仕様変更が発生した時に、当初予定外のIF文が発生したり、結局元のコンポーネントに戻したりという作業が発生する可能性があります。

サーバサイドでは非常に馴染みが深い話ですが、フロントではそこまでクリティカルではないと思われていると感じているので、ここはしっかり設計する必要があります(きちんと考えている強強エンジニアの方はごめんなさい><)。


◆ 実装詳細解説

さて、ここでは実装例で紹介したモジュールの中身を見ていきましょう。

/modules/table.ts

tableModuleではトップのチェックボックス操作で全体を操作その状態管理を行っています。細かいことをやるなら、各種Item毎のチェックボックスクリック時の操作も書くかもしれませんが、まあそこまでは良いかなと思って入れてません。

実装には、Composition APIからcomputedRefという型を利用しています。
computedが切り出しされていますが、これが通常のVueのシンタックスではできなかったことですね。

Flagが1のときは、[-]という表示になります。

/modules/item.ts

itemModuleでは、データのフェッチItemをクリックした時の処理ローディングや追加読み込み管理を任せています。

どれをどこまで切り出すかは設計に依ると思いますが、ここに各種プロパティ(テーブルカラム)固有のフィルタ検索なども書いたりしてます(本例では省略してます)。

余談ですが、reactiverefどちらを使うかで意見が様々なようですが、個人的には従来のdataとして、明確にテンプレート側にバインドしたいものは全てreactiveで宣言する、みたいにした方がわかりやすいかと思って、僕はreactiveを使っています。ref はオブジェクトを取れないという点も注意ですね。

まあModuleのreturnでtoRefsを使ってますし、実はcomputedでの宣言もReadOnly<Ref>なので、Ref自体は内部的に使ってるんですけどね。

実際のコードと全く同じではないですが、このような雰囲気で書いてみて思うことは、ロジックとして管理すべきコードと、ViewModelとして管理すべきコードを、明確に意識するようになったことです。本例ではコードが短いので微妙かもですが、同種別のロジック関連の変数や関数をまとめて切り出せるのはかなり秀逸です。

後は、なんと無くcreatedに書いていた処理や、取り扱いに困っていた定数・変数の所在を明確にすることができる(ようなポテンシャルを感じる)ので、えいやで書こうとすることが減った気がします。

もちろん、きちんとしたロジックの分離ができると、テスタビリティも確実に向上します。特に単体テストでは威力を発揮するのではないでしょうか。

とはいえ、冒頭にも書いたように、Composition APIの恩恵を受けるためにはしっかりした設計が必要なので、本当に必要になったタイミングで十分に検討して、一部分から導入すると良いと思います。
既存のSyntaxやMixinなどと併用できるのも、Composition APIの良いところですね。

◆おわりに

Finatextグループでは、一緒に働くエンジニアや仲間を募集しています!!
従来の金融ビジネスに縛られない、新たな金融サービスを開発したい方は是非ご連絡ください!!お待ちしてます!!

求人一覧はこちら
社員インタビューはこちら

Finatext

THE Finatext Tech Blog

slont

Written by

slont

Finatextのエンジニア。Vue.jsが至高。Elixir好き。個人開発アプリ-> https://app.cullet.me/ 個人ブログ-> https://www.maytry.net

Finatext

Finatext

THE Finatext Tech Blog

More From Medium

More on Finatext from Finatext

More on Finatext from Finatext

3つのGitHub Orgを1つに統合した話

Mar 5 · 8 min read

14

Related reads

Related reads

What is a Layer?

232

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade