Lightning Component開発について、
Lightningフレームワークから提供されている仕組みのみで開発するケースと
コンポーネント上にReactを仕込み、JavaScriptで開発する場合の違いを書きます。
構文
Reactは(別の環境もありますが大体)JSXで開発を行います。
また、ビュー以外の部分ではTypeScriptやBabel等のトランスパイラで開発するのが一般的かと思います。
対してLightningはLightningフレームワークが認める独自形式のみを通します。
関数が通る時点で明らかにJSONではないのですが、かといってJavaScriptとしても不正な形式です。
構文チェック
JavaScriptには eslit, jshint, jslint 等のlintingツールが存在しますが、
それらのツールをLightningコントローラに対して使用するとその独自形式よって常にエラーになってしまいます。
かと言って JsonStreamReader が厳密なチェックを行っているわけでもなく、
Lightningコンポーネントベースの開発では書いた内容がJavaScriptとして正しいのか実際に動かしてみるまでわかりません。
また、JavaScriptとして正常であってもLightningで保存が可能とは限りません。
ユニットテスト
ava, mocha, Jasmine, QUnit 等、JavaScriptには多くのテストフレームワークが存在しています。
Reactをベースに開発すれば通常のJavaScriptでの開発なので当然それらをテストすることが可能ですが、
LightningのコントローラやヘルパーはJavaScriptの形式として不正であるためそれらを使うことはできません。
ブラウザテスト
Reactであれば(Salesforceサーバーとの接続をモックする前提ですが)ローカルでのテストが可能です。
しかしながらLightningコンポーネントはSalesforce上に存在するSPAの内部の1コンポーネントとしてしか存在できず、
画面の描画が非同期で行われるためにページ遷移の検知が難しく、
また、フレームワーク側がidを変更するためにSeleniumやPhantomJSでE2Eテストを行うことは極めて困難でしょう。
ビルド/デプロイ/構成
LightningではMavensMate, Force.com IDEや開発者コンソールで開発を行います。
組織内で作成したクラスやコンポーネントはすべて1つのフォルダ内に収められ、
規模が大きくなるに連れて編集・参照したいファイルを発見するのが困難になります。
JavaScriptでの開発ではgulpからSalesforceにデプロイを行い、
テストに必要なオブジェクト・プロファイル等のメタデータもともに管理可能です。
クラスやコンポーネントは任意にフォルダ構成をきめてデプロイタスク上でそれらを統合します。
また、必要とあらば各メタデータの中身まで動的に生成することが可能です。
例えば、あらかじめ指定したデプロイ先の名前空間を付与して生成するようにしておけば
さまざまな組織にデプロイする際に名前空間に起因するエラーに苦しめられることはないでしょう。
開発ツール
両者ともChrome拡張が存在します。
AltJS
近年のJavaScriptの開発はAltJSが前提です。
TypeScriptによる静的型の導入、Babelによる将来標準になることが期待される機能の先行利用。
しかしLightningはこれらの出力するソースコードをValidなコントローラとして認めず、
で読み込み可能な独自の形式のみをLightningコントローラとしてしていできるようになっています。
JavaScriptの開発環境が日々進歩していく中、ずっとこの独自のスクリプト仕様にしばられて標準的な開発環境から取り残され続けることは想像に難くありません。
開発者人口
2016/03/14現在での aura と React のGitHub上でのWatch/Star/Fork/Contributorsの差は以下のとおりです。
| aura | React | |
|---|---|---|
| Watch | 131 | 2,817 |
| Star | 312 | 38,050 |
| Fork | 143 | 6,317 |
| Contributors | 77 | 639 |
Lightning開発者を見つけ出すことはReactに比べて困難でしょう。
(そもそもSalesforceに閉じ、潰しの利かない技術であるLightning開発者がReactと比較して人口が少ないのは当然ですが)
公開パッケージ数
Salesforceのパッケージ公開サイトであるAppExchangeに公開されている
LightningComponentパッケージの数は59です。
一方、react-componentsには2396のパッケージが公開されています。
自作コンポーネントが溜まってくれば、開発工数はかなり 抑えられる
http://www.slideshare.net/NorikoIwai/lightning-componentlightning-design-system/17
すでに世の中には多くのReactコンポーネントが存在します。
そんな中あえてSalesforceにロックインされる制限付きで
Lightningコンポーネントを自作する意味はあるのでしょうか?
Lightning vs React
ここまでの比較をまとめると以下になります。
| Lightning/aura | React | |
|---|---|---|
| コンポーネント化 | o | o |
| linting | x | o |
| ユニットテスト | x | o |
| ブラウザテスト | x | o |
| AltJS | x | o |
| 開発ツール | o | o |
| Watch | 131 | 2,817 |
| Star | 312 | 38,050 |
| Fork | 143 | 6,317 |
| Contributors | 77 | 639 |
| 公開パッケージ数 | 59 | 2396 |
まとめ
ここまでいろいろな観点でLightningと一般的なJavaScript開発を比較しましたが、
これらの内容は今までJavaScript開発者が培ってきた文化です。
要するにLightning Componentの開発環境は一言で表すと以下になります。
いろいろあるのですが、一番まずいのはJavaScriptが培ってきたさまざまなプラクティスを無神経に壊しているところです。
http://qiita.com/stomita/items/df84ab4b3f19c3e7c833
もちろん、ここにあるLightning開発に足りない部分は将来的にはある程度解決したり、
あるいはJavaScriptに関する知識を持った開発者が頑張れば対応できる部分もあるでしょう。
しかし、それらは現在でも一般的な開発で「すでに存在するもの」「より少ない労力で使えるもの」「潰しの利かないノウハウ」です。
また、Salesforce社の対応を待たなければ使用できず、その上その対応がSalesforceにロックインされた形でしか対応できないのならばそれは不毛です。
Lightningを直接使うのはやめてReact+JavaScriptで乗っ取った上で開発しましょう。