React + ReduxではないSPAフロントエンド事情

丸山です。

弊社も最近はiOSアプリやAndroidアプリだけではなく、いわゆるSPAなWebApplicationを開発しています。

SPAを採用した背景

その背景には

  • サーバーサイドで複雑なビジネスロジックを実装することになるので、サーバーサイドはScalaを利用したい
  • ScalaでHTMLを吐いてもいいのだけれど、そういうのは動的型付け言語のほうがやっぱり楽な気がする
  • だったらScalaでJSONを喋るAPIだけ作ろう
  • そのAPIと喋ってwebのユーザーインターフェイスを実現する部分はRoRにするか？
  • それともいっそSPAにしてブラウザから直接APIとコミュニケーションすればよくないか？

と、いろいろ考えたところで、まずは社内向けのツールで技術検証も兼ねてSPAでScalaなAPIとコミュニケーションするのを試してみることにしました。

まだまだ開発中なのですが、意外とうまくいっているな、というのが現在の感想です。

採用したフレームワーク

最近SPAといえばだいたいReact + Reduxというのがトレンドであるように思います。しかし弊社ではVue.jsとvue-routerを利用しています。

これには、まだまだ開発メンバーの少ない弊社では、iOSアプリケーションやAndroidアプリケーションを開発しているメンバーがSPAアプリも開発するというようなことが多発することが予測できることが影響しています。

弊社ではiOSアプリの設計についてはだいぶ方向性が見えてきていて、その内容はこの前のヤパチーでも発表させていただきました。

techblog.reraku.co.jp

上述の発表内容を見ていただければわかると思いますが、弊社ではかなり古典的なMVWな設計でアプリケーションを実装しています。

さて、上述の通り、弊社には「JavaScriptバリバリ専任マン」のような開発者はおらず、iOSアプリなどを書いている開発メンバーがJavaScriptも書くことになります。そのようなビジネス上の制約があるとき、「なるべくiOSやAndroidで使っていた考え方と同じような考え方でSPAも開発することができる」というのは無視できないメリットです。そのため、「なるべく普通のMVW」が実現できて、なおかつModelの設計については何も強制してこないフレームワークが必要になったわけです。そのようなことを考えた結果白羽の矢が立ったのがVue.jsでした。今の所この選択は間違えていなかったな、と思っています。

Vue.jsを利用したSPAフロントエンド開発事情

使っている技術スタックとしては、JSまわりにVue.js、vue-router、Babel、CSSはsass、これらを webpack でビルドして使っています。

タスクランナー的なものは採用しておらず、npm scriptを利用しています。package.jsonの一部を抜粋するとこんな感じ。

  "scripts": {
    "build": "npm run build_js && npm run build_html",
    "build_js": "webpack --progress",
    "build_html": "cp src/index.html build/index.html",

    "watch": "npm run build_html && webpack -d --watch --progress",

    "clean": "npm run clean_js && npm run clean_html",
    "clean_js": "rm -rf build/js/*",
    "clean_html": "rm -rf build/index.html",

    "test": "mocha-webpack --colors --webpack-config webpack.config-test.js \"test/**/*.js\""
  },

タスクランナーを利用しないという選択にも「専任のJavaScriptマンがいない」ということが影響していて、「なるべく覚えなければいけないことを減らそう」という判断の結果このような運用になっています。「ビルドツールがCLIインターフェースを持ってるならそれをshellから叩いてしまえばいいではないか」というのはまあ自然な発想という気はします。

テスト事情

PDSを意識してアプリケーションの動きをModelレイヤーにどんどん寄せて書いているので、UIテストは今の所行っていません。nodeを利用してApplicationServiceのテスト（あとDomainModelのテストも）をすればそれでだいたい事足りています。

というのも、ヤパチーで発表した連打マシンと同じような感じの設計で、UI上の状態もほとんどAppliactionServiceが保持するModelたちが持っていて、その状態を書き換えたいときはApplicationServiceのメソッドをdispatchする、そしてその結果状態が書き換わったらObserver経由でUIに反映する、という一方向のデータフローを守っているので、ApplicationServiceへのテストがE2Eテストに近い役割を担っていてくれている感じです。

実際Vue.jsに依存するコードはプロジェクトのうちごく一部だけとなっているため、今の所このやり方でも大きな問題は出ていません。リファクタも快適に行えています。

ただ、どこかでUIテストのノウハウとReduxのノウハウもきちんと得ておきたいところではあります。このあたりは今後の課題ですね。

まとめ

弊社で最近行っているSPA開発事情について、「こんな感じだよ」というのを書いてみました。

最後に「また宣伝かよ！」という感じでアレなんですが、株式会社リラクでは「一晩でReduxに書き換えてやるぜ！むしろ俺がReduxのメリットの伝道師になってやる！」という気概のある開発者や、あるいは「これはこれで合理的な選択！一緒に開発していきたい！」という気持ちを持ってくれる開発者、あるいは「まだ自信はないけど、設計についての話ができる仲間たちといろいろ学びつつやっていきたい！」と思ってくれるような開発者を募集しています。マジで。ほんとに無限にやることがあるんです。助けてくれ！少しでも興味があるひとは是非 @ が誰からでもDMを受け付けるようになっているので気軽にコンタクトを取ってください。ほんとに待ってます。