バンドルと要求のライフサイクルについて

このモジュールでは、Visualforce の概念と機能について概説し、それぞれに最も近い Aura コンポーネントについて説明します。すべてが明確に対応するわけではありません。Visualforce と Aura のアーキテクチャには基本的な違いがあり、アプリケーションを作成するための使用方法に関する要件も異なります。これらの違いについて、個別の機能を道しるべにしながら、できるだけ多く説明します。

ここでは Aura コンポーネント機能の使用方法を詳しく説明するわけではありません。(それについては「Aura コンポーネントの基本」モジュールを参照してください)。名前が似ているがゆえの混同を避けるために基本的な違いを明らかにするだけです。

抽象的な概念に取りかかる前に、具体的なことに目を向けましょう。個々のページまたはコンポーネントが Salesforce に保存される方法についてです。

Visualforce ページ (Visualforce コンポーネントも同じですが、そちらは今は置いておきましょう) は、Salesforce 上で単一のエンティティ、ApexPage として保存されます。Visual Studio Code 向け Salesforce 拡張機能などのツールを使用して Visualforce ページを作業のためにローカルストレージにコピーすると、個々の Visualforce ページは metadata/pages ディレクトリ内の次の 2 つのファイルとして表されます。

• yourPageName.page
• yourPageName.page-meta.xml

最初のファイルはページのコードで、2 つ目のファイルはページのメタデータ (API バージョン、モバイル設定など) です。

ページには、Apex コントローラや拡張、静的リソースといった他のアイテムとの連動関係が存在する場合もありますが、それらはページとは分離されています。ページはそれらを参照しますが、含んではいません。

Aura コンポーネントには、1 つのコードアイテムとメタデータ以上のものが含まれ、現在では、最大 8 つのコードアイテムとメタデータ (合計 9 つ) が含まれています。このため、個々のコンポーネントは、リソースを含んだバンドルに保存されます。このバンドルは、ローカルストレージに保存される場合はファイルのフォルダとして表されます。複雑なコンポーネントは次のようになります。

以降、このモジュールでは、コンポーネントバンドル内の重要なリソースについて説明します。詳細は『Lightning Aura コンポーネント開発者ガイド』の「コンポーネントのバンドル」などを参照してください。

Salesforce 拡張機能がインストールされている Visual Studio Code で Aura コンポーネントバンドルを作成するには、次の手順を使用します。

1. Mac は Command + Shift + P キー、Windows または Linux は Ctrl + Shift + P キーを押してコマンドパレットを開きます。
2. コマンドパレットで「SFDX:Create Project」を実行してプロジェクトを作成します。
3. コマンドパレットで「SFDX:Create Aura Component」を実行してコンポーネントバンドルを作成します。この単元の Challenge で、組織にファイルをリリースする Visual Studio Code を認証します。組織のユーザ名とパスワードを認識している必要があります。Trailhead Playground のユーザ名とパスワードを取得するには、「Trailhead Playground の管理」モジュールを参照してください。
   詳細は、「Aura コンポーネントのスキルとツール」モジュールを参照してください。

これは、2 つの「明らかな」重要な概念の 1 つです。ただし、実際のところいったい何が「明らか」なんでしょうか? この意味をはっきりさせてから、概念の違いがもたらす影響についてもしっかり理解していきましょう。

従来の Visualforce は「サーバ側」で実行されます。つまり、ページが要求されると、Salesforce サーバによってマークアップが処理され、結果の HTML が要求元であるユーザのブラウザに送信、表示されます。ページに式 (区切り文字「{! }」の内部にあるもの) がある場合、その式はサーバによって評価されます。グローバル変数への参照もサーバ側で解決されます。ページがコントローラプロパティにアクセスする場合も同じく、サーバ側で処理されます。他にもいろいろあります。ここでは、すべての「フレームワーク処理」がサーバ側で行われると考えてかまいません。(ここでは、Visualforce と JavaScript Remoting を併用して JavaScript アプリケーションの単なるコンテナとして使用するケースは除外しています。Web サーバとしてしか Visualforce を使用していないわけですからね。)

Aura コンポーネントのプロセスはその反対です。コンポーネントが要求されると、コンポーネントのリソースがパッケージ化され、要求元であるユーザのブラウザに送信されます。その大部分は JavaScript ですが、構造を提供するマークアップも含まれています。ブラウザによってその JavaScript が実行され、結果の HTML が既存の「ページ」に挿入される形で表示されます。(かぎ括弧内の意味については、後で説明します。)式の評価、グローバル変数、コントローラプロパティはすべてクライアント側で解決されます。

Visualforce の要求サイクル	Aura コンポーネントの要求サイクル
ユーザがページを要求する サーバがページの基礎となるコードを実行し、結果の HTML をブラウザに送信する ブラウザが HTML を表示する ユーザがページを操作すると、ステップ 1 に戻る	ユーザがアプリケーションまたはコンポーネントを要求する アプリケーションまたはコンポーネントバンドルがクライアントに返される ブラウザがバンドルを読み込む JavaScript アプリケーションが UI を生成する ユーザがページを操作すると、JavaScript アプリケーションが必要に応じてユーザインターフェースを変更する (前のステップに戻る)

アーキテクチャが大きく異なれば、結果も大きく異なります。たとえば、コンポーネントでのユーザ操作に新しいサーバ要求は必要ありませんが、コンポーネントで新しいデータを保存したり、読み込んだりするにはサーバ要求が必要です。

何も複雑ではないし、単純明快にさえ思えますよね。ただし、従来の Visualforce では、ユーザ操作には新しい目に見えるページの要求と再読み込みが伴うことを覚えておいてください。Aura コンポーネントの場合、クライアント側 JavaScript とのユーザ操作は「ライブ」感があり、反応が速いです。ところが新しいデータの読み込み時には、サーバ要求が間に入るので、急に処理が遅くなったと感じるユーザがいるかも知れません。実際には、1 つの Visualforce 要求よりも短時間で全体の処理が終わってしまうのにですよ!

Aura コンポーネントのパフォーマンスは全体的に優れていますが、サーバ要求がユーザエクスペリエンスに与える影響を考慮して設計しなければ、アプリケーションが「遅い」とユーザに判断されるおそれがあります。

この性能と評価のギャップの別の側面については、この後のトピックで説明しますが、フレームワークの動作を考えるときには、頭の中でクライアント側とサーバ側について明確にしておく必要があります。

• ユーザインターフェース開発の考慮事項
• コンポーネントのバンドル