SuPICEの開発環境紹介

　今回はSuPICEの開発環境について紹介したいと思います。実はSuPICEの開発チームは2チームに分かれています。正式な名称は決まっていないので、ここでは仮にStudioチームとDeployチームとします。簡単に担当内容を説明します。Studioは、あらかじめ用意された部品をドラッグ＆ドロップで配置して、Lightning ComponentというUIコンポーネントの見た目・挙動を定義できるツールです。Studioチームはこれを作るチームです。DeployチームはStudioチームから受け取ったパラメータを元にLightning Componentを作成しています。

　(上)あらかじめ用意された部品をドラッグ＆ドロップで配置する図

　...大雑把すぎるのでもう少し掘り下げて説明させて下さい。

　Studioチームの担当はシンプルで、Lightning Component作成用パラメータを設定するVisualforceページを作ることです。作成したパラメータはDeployチームの作成した関数に渡されLightning Componentが作成されます。PackageでいうとSuPICE Studioをメインに作成しています。基本的にひたすらJavaScriptとCSSを書くのがメインの仕事で、あまりApexやLightningには触れません。

　Deployチームは担当範囲がかなり広く、Deploy処理だけ書いているチームではありません。例えばVisualforceページ上のPreviewに表示されるコンポーネントを作成したり、Studioチームが作成したパラメータを元にLightning Componentを作成したりします。PackageでいうとSuPICE Runtimeをメインに作成しています。担当範囲がかなり広いためApex,Lightning,JavaScript,CSS一通りの技術が使われています。

　私はStudioチームなので今回はStudioチームの開発環境の説明になります。ただpackage.jsonを張り付けるのも味気ないので、簡単にジャンルを分けて、どんな風に使っていて今後どうしていきたいか書いていこうと思います。

• 言語

　今更説明の必要はないと思いますがTypeScriptは静的な型づけをしてくれるAltJSです。面倒くさがらず型をしっかりと定義するとリファクタリングや機能拡張が非常に捗ります。Reactにはpropの型チェックしてくれるpropTypesがありますが、実際に実行するまで確認ができません。TypeScriptを使えばコンパイルの段階でpropの型チェックしてくれます。地味ですが開発する分には非常に助かります。広まれtsx。

• View

　Reactを使用しています。上の図にあるようにStudioチームはパラメータを入力する箇所が非常に多いです。似たような構造が多いためReactとの組み合わせは抜群と言えるのではないでしょうか。propでstateの保存先だけ変える。ラベルなどわずかな変更だけ行う。Reactのおかげでかなり開発工数は削減できているという風に感じています。

• Model

　Modelの管理にはReduxを使っています。非同期処理を扱おうとするとRedux単体では厳しい印象が強いです。しかしSuPICEは基本的に非同期通信が少ないため、結構楽にModelを管理できています。開発開始直後からReduxを使用できたのも大きなプラスだったと思っています。現状大きな不満はありませんが、非同期処理と同期処理を切り分けるためredux-sagaを導入を検討しています。

• Task Runner

　Gulpです。gulpfile.jsの分割ができるようになるmodule「require-dir」や同期的にタスクを処理してくれるようになる「runSequence」と一緒に使っています。細かいところで簡単なpluginのようなものは自作していますが、基本的にnpmにあるmoduleを使えばほとんどの作業がコマンド一つで解決できるので非常に便利です。細かいpluginは変更するかもしれませんが基本的に大きく変更するつもりはありません。

• Test Framework

　Mocha、Expect、Sinon、Enzymeを組み合わせて使っています。ReactのテストにはAirbnb社のEnzymeを使用しています。最初はreact-addons-test-utilsを使用していたのですがメソッドごとに細かい挙動が異なっており、正直使い勝手が悪かったため移行してしまいました。Enzymeは細かい挙動の統一やlengthの追加などの機能拡張が行われており非常に便利で移行して良かったと思っています。

• Module Bundler

　Webpack、Browserifyと正直悩みました。CSSがインポートできる点とversion 2で実装される不要なmoduleをバンドルしないという特徴に引かれてWebpackを選びました。CSSがviewのファイルにインポートできれば、CSSの影響範囲をアプリ全体からインポートしたファイル内に閉じ込めることができます。クラス名の競合の確率が減りますし、競合を避けるために長ったらしいクラス名を付ける必要もなくなります。すぐにでも移行したいのですが既存のCSSファイルからの移行に思った以上に時間が取られるため、二の足を踏んでいるような状態です。(5/26現在react-selectのCSSを読み込むために、初めてCSSのインポートが実践投入されそうです。長かった...)

　かなり大雑把ですが2016年5月現在のStudioチームの構成です。上記で記述した以外にはLinting toolとしてESLint、ドキュメント作成ツールとしてESDocなどを使用しています。今後の保守や機能拡張次第でどのように変わっていくか分かりませんが、個人的には可能な限り積極的に技術を取り入れていきたいと考えています。