とあるStartupに勤めるエンジニアの技術ブログ

Salesforce、テスト関係の技術ブログなどを書く予定

Lightning Event は3度死ぬ

Lightning Salesforce

Lightning Event とは

Lightning Event とは、Lightning Component において、コンポーネント間でイベント処理を実行するための仕組みです。Lightning Event では、イベントを定義する、イベントを発火するコンポーネントに定義を記述する、イベントを受け取り処理するコンポーネントに定義を記述する、の3ステップが必要となります。

First Impact

問題点

それは、Lightning Component をまともにコンポーネント分割してコンポーネント間のイベント処理を Lightning Event で行おうとしたときに訪れます。
Lightning Event も Lightning Component などと同様にバンドルという単位で扱います。このバンドルにイベントの定義だけを記述します。問題はこのバンドルがすべて1階層内で管理されるため、まともにコンポーネントを分割し、イベント処理を書いていくとものすごい数のバンドルが作成されることになり、管理不能になっていきます。

対応策

対応策としては、下記の2つが考えられます。

  • まとめにコンポーネントを分割しない
  • Lightning Component はあくまでも外側とのI/Fの定義に徹して、内部は別ライブラリ(React.jsなど)を利用する

前者はコンポーネント志向を捨てることになるので、後者のほうが優れたやり方ではあります。ただし、モダンJavaScriptのスキルが必要となるので、JavaScriptが得意ではないエンジニアがいきなり採用するには少しハードルがあります。トレンドは、モダンJavaScriptを利用して開発する流れとなっているので、頑張って覚えていってもよいかもしれません。

Second Impact

問題点

それは、別のパッケージにある Lightning Component を Lightning Event で連携しようとしたときに訪れます。
Lightning Event は型付け言語に相応しく、ソースコード中にある場合は定義を参照してバリデーションしており、定義が見つからない場合はソースコードをSalesforce組織にデプロイすることができません。

そのため、他のパッケージ中にあるコンポーネントを参照すると、自動的に基本パッケージと拡張パッケージというような主従の関係となってしまいます。これは、 Lightning Event でも同様に機能しますので、他のパッケージの Lightning Event を呼び出すパッケージを作ろうとすると、呼び出し元のパッケージに依存するようになってしまい、単独ではインストールすることができなくなってしまいます。

対応策

対応策としては、Lightning Event を利用する場合は、直接的なイベントのワイヤリングを諦めるしかありません。それぞれのパッケージでは別々に Lightning Event を発火・受け付ける処理を作成し、2つのパッケージのコンポーネント間のイベントを受け渡すワイヤリング用のコンポーネントを作成することでやりたいことができるようになります。

自動的にイベントをワイヤリングできなくなってしまうところですが、このワイヤリングコンポーネントを2つのパッケージの拡張パッケージとして作成してやることで、コーディングする必要はなくなります。
2つのパッケージにある Lightning Component を Lightning App Builder で配置し、合わせてワイヤリングコンポーネントを配置してやることでイベントの受け渡しを実現できます。

Third Impact

もうすぐ ltng:sendMessage イベントが実装されるようです。
このイベントを利用すると、新しいイベントを定義せずに ltng:sendMessage イベントでメッセージ(JSON形式)をチャンネルを指定してイベント発火し、 で受け取りハンドルして対応する処理を記述できるようになるようです。これによって、ひとつ目、ふたつ目の問題点を回避できそうです。

ところが…

おぅ…。
希望の光と思われた ltng:sendMessage も解ではないと…。
問題として認識されて、解決に向けて対応中とのことなので、もう少し様子を見ましょう…。


Enjoy Lightning!