WordPressで全面的にVue.jsを導入してみた(SPA実装ではない)

以前SPA実装のWordPress案件に関わったのですが、Rootingをフロントで持つことが強いられる一方でWordPress独自のURL排出にバックエンドとフロントエンドどちらも意識しないといけないことが結構大変でした。

itaoyuta.hatenablog.com

なのでWordPress実装にVue.jsを利用する場合SPAはないなという所感だったのですが、その一方でどのように関われるか考えた結論、単純に都度ページを読み込むスタンダードな実装がほとんど文句なくよかったです。

開発環境について

WordPress: 4.9.1
WebPack: 3.8.1
Vue: 2.5.3

WordPress独自テーマのViewファイルの感じ

<?php get_template_part( 'partials/head' )?>

<div id="top"></div>

<script src="<?php bloginfo('template_directory'); ?>/js/top.bundle.js"></script>

<?php get_template_part( 'partials/foot' )?>

このような感じで、WebPackでまとめられたページごとに生成されたVueファイルを読み込みます。
そして中身のvue側で、WP REST APIを利用し必要な投稿データ等を取得してページを構築します。

Vue.js側の構成

f:id:itaoyuta:20171228133936p:plain

起点となる共通app.jsを用意しつつも、ページごとのjsを用意して、そこから専用のvueコンポーネント及び共通コンポーネントを拾ってくるような形で構成しています。

メリット / デメリット

  • メリット
    • 組み込みという無駄な作業が発生しないためbackendとfrontの無駄な共有ごとが減る
    • phpにフロントのソースが混入しないので、見渡しがよい
    • backend側の稼働コストが極端に低いがfrontの稼働コストはそこまで変わらない
  • デメリット
    • Vue.js自体の学習コスト
    • 受託作業の場合納品形態に念のため確認をとった方がいいかも
    • ページ遷移時、ヘッダー等の共通パーツも仮想DOMとして再作成された上でレンダリングされるタイミングがメインフローのdisplayed以降に評価されているからか、微妙にページ遷移したときにチラついて見える*1
      • 静的に記述されたDOMであれば、DOMとStyleを事前評価した上で前ページと同様だった場合レンダリングされた場合チラつきがおきない

大きいデメリットで言えば、ページ遷移の際のチラつきを感じる場合がある箇所かと思いますが、これは実装方法を探ればなんとかなりそうな気もしています。
具体的に言うとヘッダー等条件によってアニメーションをつけたりする場合、その条件評価を待ってしまうため、非同期でとってくるデータをまったりしてしまうと、その間表示されないみたいなことがおきている感じがします。
このあたりは、要調査といった課題となりました。

まとめると

トータルで見ると、積極的に採用しない理由はないくらいよい感じなので、しばらくこのスタイルで開発してみたいと思っています。
backendがAPIのみ考えればよくて、フロントがデータを元に画面を構築していく分業が非常にシンプルに終わりそうでいい感じです。
さらに求めるなら、GraphQLでフロントがデータオブジェクトを好きに生成するところまでいければ最高ですが、ひとまずはREST APIでこのスタイルが根づけば良い感じですね。