2015今回は現在所属しているspicelifeのサービスの1つであるSPOTLIGHTSにVue.jsを採用した話をしようと思います。SPOTLIGHTS自体は一般的なRailsアプリケーションといって問題ない作りになっているので、既存のRailsアプリケーションにどういった形でVue.jsを投入していったかを中心に書いていきます。Vue.js採用前の状況SPOTLIGHTS初期のJavaScriptはHTML/CSSと共に外注し納品してもらったものです。フレームワークといった類はほぼ使っておらずjQueryに頼りきったコードでした。当時は様々な事情によりこれはこれで妥当な判断だったと思うですが、今後社内でメンテナンスしていくうえで足かせになるであろうというのはなんとなく予想ができていました。jQueryのイベントハンドラやDOM操作がひとつのファイルにひたすら連なっているという状況だったためです。そのため2014年の12月にVue.jsの採用を決定し、少しずつ置き換えていきました。Vue.jsに決定した理由JavaScriptのフレームワークを採用するにあたって、Knockout.jsとVue.jsのどちらかにしようと考えていました。フルスタックのフレームワークを除外したのはそのライブラリが廃れた場合の移行や、既存のJavaScriptを少しずつ置き換えるコストを考えた場合にあまり向いていないと判断したためです。React.jsも考えましたが、私含めチーム全体のJavaScript力を考えた時に少々チャレンジングすぎるかなと思いこちらも除外しました。Knockout.jsではなくVue.jsを採用した理由ですが、簡単に言ってしまえば私の独断と偏見です。Knockout.jsは弊社エンジニアのid:asonasが使用経験がありましたがVue.jsの使用経験を持つメンバーが社内にいなかったため、せっかくだし新しいもの触ってみようという気持ちで決めました。Vue.jsの採用でネックになりそうなIE対応ですがSPOTLIGHTSではIE8はサポート外だったというのもあります。Assetsを採用しました。SPOTLIGHTSは元々JSなどは外部のライブラリも含め同じgitリポジトリ内で管理されていました。その為、本番環境にNode.jsはインストールされておらず今回のためにNode.jsをインストールするのにも少々抵抗がありました。新しい何かを採用する際に同時に新しいものを採用すると混乱しがちだからです。AssetsはGemfileに1行追加するだけでVue.jsをインストールすることができました。'https://rails-assets.org'導入初期はonClickをv-onに置き換え導入としてまずはonClickで制御していた上記画像のようなモーダルの開閉をVue.jsに置き換えました。元々は.openModalというクラスにイベントハンドラをあてていましたが、それを削除しVueのメソッドをv-onで呼ぶようにしました。同時にモーダルを開閉する処理を行っていたJavaScriptも全てCoffeeScriptに書きなおしました。この時点ではイベントハンドラを置き換えただけなのであまり大きなメリットはありませんでした。コードの見通しは若干よくなりはしましたが、モーダルは至る所で使われていたので影響範囲が広く一部でモーダルが開かない/閉じないなどのバグを発生させてしまったぐらいです。私自身まずVue.jsに慣れるという点にフォーカスしていたので置き換えやすいv-onから使いはじめるというのは妥当な判断だったと思います。データバインディングでVue.jsのメリットを感じるVue.jsのメリットが目立つようになってきたのは私達がranunculus(ラナンキュラス)というコードネームで呼んでいるリニューアルへの作業が始まってしばらくした頃です。SPOTLIGHTSはお花を贈るサービスですので当然贈るお花を決める必要があります。お花を選択するページも今回のリニューアル対象でした。新しいお花の選択ページではクリックしたお花を同画面の下の部分で表示するようになっています。Vue.jsのデータバインディングを使うことでDOM操作を自前で書かなくとも、Vueのメソッド内でdataの値を変更することでプレビューも自動的に変わるようになりました。product.imagePath')今回のリニューアルではユーザーがなにか操作(大体においてクリック)したら、別の箇所も書き換えるというケースがそれなりにありデータバインディングのお手軽さには非常に助けられました。jQueryでも当然同じことは実現できますが実装の手間は大分軽減されたと感じています。ページごとにVueインスタンスを作り肥大化を抑えるSPOTLIGHTSはRailsアプリケーションですのでJavaScriptのファイル群は全てSprocketsによってapplication.jsに統合されます。よってVue.js採用時点でページごとにJavaScriptを読み分ける仕組みはありませんでした。最初のうちはひとつのVueインスタンスに全てのコードを詰め込んでいました。想像に難くないと思いますが当然肥大化します。Vue.jsにはmixinの仕組みがあるのでファイル自体は分割できるのですがインスタンスの肥大化自体は避けられません。厳しいと感じたので対応することにしました。案としてはふたつありました。ひとつは各ページごとにJavaScriptファイルを用意し個別に読み込ませること。Sprocketsはapplication.rbの指定で個別にファイルを用意することができるので不可能ではありませんでしたが、既存ページに個別に読み込む処理を記述していくのは大変だなと思い却下しました。採用した案はもうひとつのapplication.js上で読み込む処理を切り替えることでした。attributesを持たせその値を見て分岐させます。それ以外のページの処理この方法の利点は既存のページの影響を最小限に少しずつ置き換えていくことができることです。あるページに関する実装や修正が発生したときに、それらとあわせてそのページ専用のVueインスタンスに置き換えていきました。switch文の複雑さを抱えてしまいましたが、Vueインスタンスはページごとに分割されたおかげで肥大化を抑えることができました。コンポーネントの利用Vueインスタンスをページごとに作るようにしたといってもページによってはそれなりの複雑さになることがありました。そのためコンポーネントを用いて更に分割することにしました。上記画像はお花のお届け日を選択するカレンダーですが、ここですることは大まかに3つあります。fieldの値に入れるこの3つのうち最初の1つをコンポーネントとして実装しました。このカレンダーは選択されたお届け日に対して、お花の購入締切日の計算やカレンダーの各要素のクラスの割り当てなどそれなりに複雑な処理が必要でした。その部分をコンポーネントとすることで、日付選択のUIに関する部分だけど1つのまとまりにできます。fillFormAndPreview')このコンポーネントは選択された日付を$emitを使ってイベントと一緒に通知しますが、それをどう処理するかに関しては関与しません。イベントを受け取る側では選択に関する細々とした処理がコンポーネント内に隠蔽されるため、その日付をどう処理するかにだけ集中すればよくコードの見通しもよくなります。することでカレンダーを別のページでも使えるようになりました。上の画像は左右それぞれ別のページですが、同じコンポーネントを使っています。それぞれ選択された日付に応じて行うべき処理が若干違うのですが、それはイベントを受け取った側で処理するだけなのでコンポーネント側では気にする必要がありません。テンプレートはscriptタグを使用コンポーネントで使用するテンプレートはscriptタグで定義するようにしました。いうとカレンダーのHTMLなどは元々Hamlで書かれていたのでそれらの資産をそのまま流用したかったのと、チームのエンジニアがHamlに馴染んでいるためこの方式ならば抵抗感もないだろうという判断のためです。省略%delivery-calendarコンポーネントのタグとセットで必ずscriptタグも必要になってしまいますが、Railsのpartialの仕組みを使えばあまり問題になりません。まとめさて、いかがだったでしょうか。プロダクションとして投入しているRailsアプリケーションにVue.jsを採用した事例として参考になれば幸いです。現時点で課題はいくつか残っており、例えばVueインスタンスを振り分けるためのswitch文がそれなりにでかくちょっと無視できない感じになってきました。この問題に関してはなんらかのルーティングライブラリの採用などを検討しています。いえ基本的にはチームからの評判もよく、ここ2ヶ月の進捗を見ている限りではVue.js採用は概ね成功といえる状況です。今後もよりよいサービスを作れるよう色々挑戦していきたいと思っています。ありがとうございました。