なんとなく jQuery で作る Web アプリから Vue.js への挑戦!!! (ShanonAdventCalendar2017・2日目)

このエントリーをはてなブックマークに追加

この記事は ShanonAdventCalendar2017 ・2日目の記事です。

どうも、前回の投稿からはや9ヶ月ほど経ちました。 @__munepom__ です。

今回は、ほぼ 10 年モノ熟成 Perl の倒し方 (AWS 移行編) の続きではなく、
ここ半年ほど手がけていたシナリオエディタ の開発にまつわるお話をつらつらと書こうと思います。

(ほぼ 10 年モノ熟成 Perl の倒し方 (Docker 移行編) は、 来週のお楽しみということで)

シナリオエディタとは?

の前に、そもそもシナリオ機能とは何か?について軽くご説明せねばですね。

シナリオ機能とは、マーケティングオートメーション (MA) のオートメーション機能の1つでして、
リードとのコミュニケーションを設計・自動運用する機能のことです。
(結果として、エンゲージメントを構築できると良いな、という)
弊社プレスリリースもご覧いただければと思います。



んで、シナリオ機能の編集画面がシナリオエディタということになるわけですが、
これまでの SMP 画面とは 異なる画面が必要となるだろうということで、
開発メンバーとして誘拐招集され ました。
( 単純に、 JS 得意そうなので、という理由ですw)

いざシナリオエディタ開発

設計 #1

いろいろ考えた末、サーバ側の API を叩いてあとはクライアント側でいい感じに処理する SPA ライクな設計としました。

これまでの SMP 画面のようにサーバー側でレンダリングして、ちょっぴり jQuery で頑張るという構成ではない、というチャレンジとなりました。

設計 #2

SPA っぽくやることは決まったので、アプリの状態管理の設計に初期から気を遣いました。
というのも、これまでサーバーサイドレンダリングと jQuery でやってきたことは、
  • ある DOM をどのように操作するか?
  • イベント発生したらどう DOM を操作するか?
といった DOM 操作に集中していた JS であって、
クライアント側で状態を管理する、というものではなかったためです。

SPA の場合、クライアント側の状態を管理して、それを DOM に反映させるだけ!という設計にしなければ、後々破綻すると感じていたため、そのやり方を勉強しました。

調べた結果、 Facebook の編み出した Flux のような、
データを一方向に流して画面を更新するやり方が良さそうだと分かったので、
それが極力実現できるよう、モジュールを 作るということにしました。
(一方向、というのは語弊があるかもしれませんが、まあそういうイメージという ことで)

JS bundle でやっていきしました

これまでの SMP では、何となくグローバルな空間にオブジェクト生やしてなんかほげる、というやり方で頑張ってきたようです。

が、 munepom はグローバル空間汚染ウェーイというやり方は嫌いなので、モジュール化して Babel でトランスパイル後に Webpack で bundle するやり方としました。

webpack.config.js の書き方は調べるといろいろ出てくるので、皆様の民間療法を参考に頑張りました。

ライブラリ選定 小話 #1

ユーザーのみなさまにシナリオの状態をわかりやすく提供することがキモになるシナリオエディタですが、そのグラフ描画のため、 JointJS を採用しました。
( 価格、ライセンス、メンテナンス頻度を比較 した結果です)

このライブラリが Backbone.js ベースだったので、クライアント側の描画フレームワークをどうしようか悩みました。。。

React + Redux か Vue.js + Vuex は ぜひ導入してみたかったのですが、
B2B の ウェブアプリケーションですと、
限られた期間での開発でクロスブラウザ対応という地雷処理やりきれないのでは?
という懸念から、開発初期では導入を見送りました。

ライブラリ選定小話 #2

さて、グラフ描画部分は何とか形になってきましたが、、、

いざ作ってみると、 入力タイプやバリデーションが動的に変化する入力フォームの生成どうしよう問題が (やはり) 発生しました。

そこは JSON Schema ベースでしょ!ということで、
いい感じに処理してくれそうなライブラリとして、 AngularJS ベースや Vue.js ベースのものが見つかり、結局 Vue.js ベースのライブラリを導入しました。

(うん、 Vue.js は導入しました。てへ。)

あとはがんばる

シナリオエディタ 、2名で開発が進みました。

フォーム領域、グラフ 領域、ヘッダ領域といったパーツ毎 にモジュールを作成し、それらを init 用スクリプトで初期化してほげる構成にしました。

あとは、適宜 EventEmitter を dispatcher として利用し、状態を連携して調整したりを繰り返し、何とか形にできました。

(もっと 良いやり方はあると思いますが、 リリース日程が決まっていたのでお察しください。。。)

Unit Test

さて、 UT ですが、既存 製品の一部では Jasmine + Karma を利用しています。

2017年で新規に UT フレームワーク導入するなら、、、 Jest かな?
ということで導入してみました。
こちらも検索すると民間療法が色々あるので、参考になります。

(jsdom で SVG がサポートされていないバージョン使ってるよ問題が発覚しましたが、、、当面モックで頑張るしかないのかな、、、???)


そんなこんなで ふりかえり

Keep

  • 開発チームに UI/UX 担当がいたため、モックを参考に することでコーディングに集中できました。
    • 生産性が劇的に向上しました。
  • 海外にいる上海チームのメンバーと開発を進めましたが、 Slack Call と画面共有が案外活躍しました。
    • メッセージ送って終わり!ではなく、実際に同じ状況をイメージできるような情報共有が大事 だと思います。
  • リリース日程が決まっていたので、実装の優先順位を スプリントレビューで適度に決めながら進められたの良かったです。
  • 実装難度は相当高く、メンバーの JS スキルが劇的に 向上したと思われます。
    • 戦いながら強くなるのです。
  • JointJS に p-r 取り込まれました。わーい!

Problem

  • 初めから Vue.js + Vuex 採用しとけば良かったかな。。。
    • 途中から State 連携しようとすると、案外めんどいですこれ。。。
  • わかっちゃいましたが、テストがすっごく 大変ですね。。。

Try

  • Vue.js で全面書き換えしてみたいのです!

みなさまも素敵な JS ライフを!

╭( ・ㅂ・)و ̑̑ グッ !
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...