管理画面を Smarty から Vue.js に一新した話

PHPエンジニアの堀田です。
もう一回言っておきますがPHPエンジニアです。

しばらくリファクタリングを続けたおかげで、だいぶ見通しが良くなってきたな〜と喜んでいたのも束の間。

「Smartyイケてないんで、フロント技術の入れ替えしたいですね」

マネージャーからの無茶振りありがたいお言葉。
より優先の課題があるのでと後回しにされていた問題にも焦点が当たりました。

導入にあたっての意見

最終的には「やる」ということになったのですが、決定打だったのは微調整により手動のテストに繰り返しかかる工数のあたりでした。
他にも出た意見は以下のような感じ。

賛成 (メリット)

  • Smartyはページの表示出力だけなので、ページ遷移やデータのやりとりは独自実装。JSが無法地帯になりがちなのでやめたい。
  • JSフレームワークに移行すれば表示系でまとめて開発・管理できる(疎結合な開発ができる)
  • テストが書ける(時間はない)(…)

反対 (デメリット)

  • 入れ替えのコストがかなりかかることに対して短期的にメリットがない
  • 目的があっての導入ではないため、機能は変わらない
  • 不特定のユーザーへ向けたサービスではなく業務システム寄りのため、見た目や画面の使いやすさは二の次

フレームワーク・プラグイン

経緯はそこそこに、本題の開発について話を進めましょう。

管理のしやすさと理由にタイトルの通りVueを採用しています。
採用したものと理由は以下の通り。

◆ Vuetify

基本的なデザインセットと表示コンポーネントが入ったフレームワーク

  • Googleマテリアルデザインを採用している
  • UIコンポーネントの使い勝手が良さそう
  • 日本語のドキュメントもある

VuefyやBootstrapも候補にあがりましたが、現状を維持して長期的に使えそうな技術にするのが目的だったので採用。
個人的にはVuefyがシンプルで使い勝手も良いので好きです。

◆ vue-router

ページ遷移の管理用
URLで情報共有できるようにしたかったのでHistory-APIを採用してます。

◆ Axios

サーバーサイドとの通信処理用
Fetch-APIを採用したかったけれど、IEが対応していないということで保留。
将来的に置き換えも検討できるように実装しました。 developer.mozilla.org

◆ winston

ログ出力用
開発と本番で出力レベル切り替えでデバッグ情報の漏洩を防ぎます。

気を付けたこと

  • 無駄に何でも入れない
  • 通信処理・エラーハンドリングは統一する

初期設計では最低限に絞って、必要になってから検討するということで進めています。

Vuexは複雑なデータ入出力は無いため採用していません。 データ操作が多いのであればReactやAngularの導入を検討していました。(TypeScriptで開発する予定だったので最初の候補には上がっていましたが、規模が大きく無いこともありテンプレート管理のしやすさをとりました)

苦戦したポイント

◆ TypeScript

Vueは型もサポートしていますが、癖があってここはマイナスに感じました。
今回はサーバーサイドがPHPで、他の言語に比べ型に厳密でなかった歴史もあるので、改修が波及して量が多くなってしまうということも。
ここはVueのメリットを削ぐ部分なので、開発メンバーによってはあえて型を厳密にしないという選択もありです。

それでも型をつけたいという場合には、Vue3.0からのComposition APIを利用することで利用しやすくなるとのこと。
正式リリース前に着手したのでプラグインを利用して開発を進めています。
せっかく全部作り直すのであれば厳密に書いておきたいとのことなので、頑張ります。
vue-composition-api-rfc.netlify.com

◆ vue-cliのホットリロードが動かない

デフォルトで保存をかけたら更新がかかるようになっている筈で、環境は同じなのに、なぜか自分だけ反映されない…

これは調べたらwebpackのファイル監視設定の問題とのことでした。

webpack.js.org

しかし設定したら解決すると思いきや、今度は繰り返しリビルド処理が実行されてしまって時間がかかる… これは自動保存にしていたので表示ファイルを切り替えるたびに更新が開始されてしまったようです。遅いなと思っていたらPCが悲鳴を上げて気づきました。
aggregateTimeoutの項目が例では300msとなっていますが、大きめに設定すると解決します。

上記リンクは英語ドキュメントなのでちなみに、

aggregateTimeout: ファイル変更を検知してから一回のリビルドに含める待ち時間  
poll: ファイル変更検知間隔  

らしいです!

まとめ

長期的な保守・開発を見据えたら、放置というのは現状維持ではなく劣化になると思っています。
開発側へのメリットだと後回しにされがちですが、結果的にユーザーへも還元されることを意識して開発していきたいですね。