Lightning Componentベースの開発とReact+JavaScript開発環境の差


Lightning Component開発について、
Lightningフレームワークから提供されている仕組みのみで開発するケースと
コンポーネント上にReactを仕込み、JavaScriptで開発する場合の違いを書きます。



## 構文

Reactは(別の環境もありますが大体)JSXで開発を行います。
また、ビュー以外の部分ではTypeScriptやBabel等のトランスパイラで開発するのが一般的かと思います。

対してLightningはLightningフレームワークが認める独自形式のみを通します。

https://github.com/forcedotcom/aura/blob/master/aura-util/src/main/java/org/auraframework/util/json/JsonStreamReader.java

関数が通る時点で明らかにJSONではないのですが、かといってJavaScriptとしても不正な形式です。

## 構文チェック

JavaScriptには eslit, jshint, jslint 等のlintingツールが存在しますが、
それらのツールをLightningコントローラに対して使用するとその独自形式よって常にエラーになってしまいます。

かと言って JsonStreamReader が厳密なチェックを行っているわけでもなく、
Lightningコンポーネントベースの開発では書いた内容がJavaScriptとして正しいのか実際に動かしてみるまでわかりません。
また、JavaScriptとして正常であってもLightningで保存が可能とは限りません。

http://qiita.com/twk/items/fa86e084736222b0b857

<!--
コントローラのバリデーションがあるページ:
https://github.com/forcedotcom/aura/blob/master/aura-impl/src/main/java/org/auraframework/impl/javascript/parser/handler/JavascriptControllerHandlerProvider.java

Lightningがトークンとして認めるものの定数クラス:
https://github.com/forcedotcom/aura/blob/master/aura-interfaces/src/main/java/org/auraframework/util/json/JsonConstant.java
-->

## ユニットテスト

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にデプロイを行い、
テストに必要なオブジェクト・プロファイル等のメタデータもともに管理可能です。
クラスやコンポーネントは任意にフォルダ構成をきめてデプロイタスク上でそれらを統合します。
また、必要とあらば各メタデータの中身まで動的に生成することが可能です。

http://qiita.com/mino0123/items/4c5d641c9f25a2875368

例えば、あらかじめ指定したデプロイ先の名前空間を付与して生成するようにしておけば
さまざまな組織にデプロイする際に名前空間に起因するエラーに苦しめられることはないでしょう。

## 開発ツール

両者ともChrome拡張が存在します。

* [Salesforce Lightning Inspector](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/inspector_install.htm)
* [React Developer Tools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi)

## AltJS

近年のJavaScriptの開発はAltJSが前提です。

TypeScriptによる静的型の導入、Babelによる将来標準になることが期待される機能の先行利用。

しかしLightningはこれらの出力するソースコードをValidなコントローラとして認めず、

https://github.com/forcedotcom/aura/blob/master/aura-util/src/main/java/org/auraframework/util/json/JsonStreamReader.java

で読み込み可能な独自の形式のみをLightningコントローラとしてしていできるようになっています。

JavaScriptの開発環境が日々進歩していく中、ずっとこの独自のスクリプト仕様にしばられて標準的な開発環境から取り残され続けることは想像に難くありません。

## 開発者人口

2016/03/14現在での [aura](https://github.com/forcedotcom/aura) と [React](https://github.com/facebook/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のパッケージが公開されています。

> 自作コンポーネントが溜まってくれば、開発工数はかなり 抑えられる
<cite>http://www.slideshare.net/NorikoIwai/lightning-componentlightning-design-system/17</cite>

すでに世の中には多くの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が培ってきたさまざまなプラクティスを無神経に壊しているところです。
<cite>http://qiita.com/stomita/items/df84ab4b3f19c3e7c833</cite>

もちろん、ここにあるLightning開発に足りない部分は将来的にはある程度解決したり、
あるいはJavaScriptに関する知識を持った開発者が頑張れば対応できる部分もあるでしょう。
しかし、それらは現在でも一般的な開発で「すでに存在するもの」「より少ない労力で使えるもの」「潰しの利かないノウハウ」です。

また、Salesforce社の対応を待たなければ使用できず、その上その対応がSalesforceにロックインされた形でしか対応できないのならばそれは不毛です。

Lightningを直接使うのはやめてReact+JavaScriptで乗っ取った上で開発しましょう。

<!--
## React(JSX)の学習コストの低さ


## エラーメッセージに原因を特定できる情報がない

ERROR Error message: 内部サーバエラーが発生しました。
エラー ID: 

Lightning開発者でこのメッセージをみたことがない人はいないでしょう。
現在のLightningはサーバーとの通信でなにか問題があると(型の不整合、サーバー側の型が通信に対応していない etc.)とりあえずこのエラーを返してきます。
メッセージには原因を特定するための情報が一切載っておらず、開発者は直近で追加したコードの内容から
エラーの原因について推測と調査を反復的に行わなければなりません。
-->