他の表示方法について学ぶ

学習の目的

この単元を完了すると、次のことができるようになります。

リストとイベントを使用する方法を説明する。
サードパーティの JavaScript ライブラリとスタイルシートを使用する方法を説明する。
Lightning Web コンポーネントの画像を最適化する。
Lightning 基本コンポーネントの利点を説明する。
ライフサイクルの表示とリフローを使用する方法を説明する。

はじめに

多くの場合、Lightning Web コンポーネントのパフォーマンスは前の単元で紹介したベストプラクティスを使用して高めることができますが、パフォーマンスを向上させるために使用できる表示方法は他にもあります。

Lightning Web コンポーネントをさらに高速化するためのアイデアをいくつか紹介します。

リストを作成するときは、for:each または iterator のいずれかを使用してください。相違点として、iterator には配列の最初と最後の項目に特別な動作を適用できる first プロパティと last プロパティが含まれます。
```
<template for:each={contacts} for:item="contact">
  <li key={contact.Id}>{contact.Name}, {contact.Title}</li>
</template>
```
カスタムリストコンポーネントを作成するときは、無数のリスト項目の作成をサポートしないでください。そうした場合、特に大量のレコードがある大規模組織で、パフォーマンスが著しく妨げられる恐れがあります。ページネーションのメカニズムを提供するか、リストを仮想化 (限られた数のリスト項目コンポーネントを再使用してリハイドレート) してください。
各リスト要素には、すべての子で値が一意の key を含める必要があります。
リスト内で Lightning Web コンポーネントを使用して機能をカプセル化するときは注意してください。オーバーヘッドが大きく増加し、パフォーマンスの問題が生じる恐れがあります。特に大きいリストの場合には注意が必要です。

イベント

イベントの活用はコンポーネント間での通信に優れた方法です。Lightning Web コンポーネントは標準 DOM イベントをディスパッチするため、開発者は DOM 内のイベントをリスンすることもできます。コンポーネントによってカスタムイベントを作成してディスパッチすることもできます。コンポーネントのコンテインメント階層の上位と通信するには、イベントを使用します。イベントリスナーは、addEventListener() を使用して宣言的またはプログラムで添付できます。

イベントとイベントハンドラーを活用するときは、次の点に留意してください。

イベントハンドラーの数を必要最小限に抑えます。各ハンドラーでオーバーヘッドが発生するため、作成しすぎると、アプリケーションのパフォーマンスが遅くなる可能性があります。
bubbles と composed を使用した親-子コンポーネントのイベント伝達について必ず理解してください。通常、混乱が最小限に抑えられるため、イベントを bubbles:false と composed:false に設定します。このようなイベントは、DOM ツリー内で上に伝達されず、シャドウ境界を越えることもありません。bubbles:true と composed:true を使用してイベントを作成する場合、イベントを生成するコンポーネントの API 契約を作成します。
1 つの Lightning ページ内または複数のページにわたり兄弟コンポーネント間で通信するには、Lightning Message Service を使用できます。Visualforce、Aura、LWC、ユーティリティバーの各コンポーネントとコンソールアプリケーションのさまざまなページタブで機能するという利点があります。
リスナーをコンポーネントのライフサイクルの一部でないもの (ウィンドウオブジェクト、ドキュメントオブジェクトなど) に追加する場合、ユーザー自身がリスナーを削除する必要があります。イベントリスナーを削除するには、disconnectedCallback ライフサイクルフックで removeEventListener() を使用します。そうしないとメモリリークが発生する可能性があり、そうなった場合、ユーザーがブラウザータブを閉じるか更新するまで Lightning アプリケーション全体のパフォーマンスが徐々に低下します。
リストを操作する場合は、イベントが上位に伝達されるようにし、すべてのリスト項目に個別のイベントリスナーを登録する代わりに親要素に 1 つのイベントリスナーを登録すると、アプリケーションのイベントリスナー数を大幅に削減できます。こうすることで、パフォーマンスが向上する可能性があります。

サードパーティの JavaScript ライブラリとスタイルシート

可能な場合は、不必要なライブラリの連動関係を削除します。また、サードパーティのライブラリを Lightning コンポーネントで使用することを決定する前に、そのライブラリが本当に必要かを再評価してください。特に DOM 操作ライブラリ (jQuery など) と UI ライブラリ (Bootstrap または jQuery UI など) は、LWC の使用時に必要でなくなった可能性があります。サードパーティまたは独自のカスタムスタイルシートは、Salesforce Lightning Design System (SLDS) でニーズを満たすことができない場合のみ使用します。

DOM 操作ライブラリ

近年、JavaScript は大きな進歩を遂げました。jQuery のようなものがないと使用できなかった多くの DOM 操作ユーティリティが、この言語で標準になっています。Lightning Web コンポーネントのような最新のフレームワークによって抽象化も提供され、jQuery の重要性は低くなっています。

UI ライブラリ

Bootstrap、jQuery UI のような UI ライブラリの使用は避けることをお勧めします。このようなライブラリによって便利なコンポーネントが提供されますが、独自の UI アイデンティティを持っているため Lightning Experience のアイデンティティと競合する可能性があります。Lightning 基本コンポーネントと SLDS では、一貫性のあるユーザー環境と、類似した機能が提供されます。

MVC (Model-View-Controller) フレームワーク

大まかに言うと、React や AngularJS のようなライブラリの焦点は、Lightning Web コンポーネントフレームワークと同じです。つまり、コードの整理とコンポーネントを作成するユーティリティを提供します。コンポーネント内で LWC と別の MVC フレームワークを併用することはお勧めしませんが、Lightning Experience 内で Lightning コンポーネントをコンテナとして使用して、他のフレームワーク (React や AngularJS など) で構築されたコンポーネントをホストすることは可能です。ただし、このトピックについてはこの単元では扱いません。

カスタムスタイルシート

サードパーティの CSS スタイルシートを使用したり、独自のスタイルを作成したりすると、パフォーマンスの問題が生じる可能性があり、エンドユーザーにとって UI が一貫していないように見える場合もあります。開発者は、エンドユーザーのために美しくリッチな UI 環境を作成するために、Salesforce が開発した Salesforce Lightning Design System (SLDS) について十分に理解する必要があります。スタイルや CSS だけではなく、社内エンジニアが使用するデザインガイドラインと原則のほか、ブレッドクラム、モーダル、アラートのような一般的な開発者ニーズに対応するコンポーネントブループリントも含まれています。色、フォント、スペーシング、サイズのみならず、タッチのビジュアルデザイン属性が保存された素晴らしい設計トークンリストも備わっています。

Lightning に直接組み込まれており、開発者が独自の CSS を作成して維持する必要がないため、SLDS を活用すれば、開発者がコンポーネントを作成するときの時間が短縮します。

縮小バージョンのライブラリとスタイルシートを使用する

サードパーティのライブラリをどうしても使用する必要がある場合、必ず縮小バージョンのライブラリとスタイルシートを使用してアプリケーションのパフォーマンスを高めてください。

Lightning 基本コンポーネント

独自のカスタム Lightning コンポーネントを作成する前に、提供された基本コンポーネントのライブラリについて十分に理解してください。これには、lightning-input-field、lightning-record-form などが含まれます。この基本コンポーネントを活用すると、開発時間を大幅に短縮できます。たとえば、ユーザーに提示する大きな赤いボタンが必要な場合、lightning-button を使用すると簡単です。

<lightning-button variant="destructive" label="Destructive" onclick={handleClick}></lightning-button>

Lightning 基本コンポーネントの使用には、他にも次のような利点があります。

スタイル: Lightning 基本コンポーネントは Lightning のネイティブなデザインでスタイル設定されています。
パフォーマンス: Lightning 基本コンポーネントはクライアント側ですでに読み込まれているため、追加で必要となるダウンロードや処理はありません。パフォーマンスを最適化する取り組みは、Lightning 名前空間のコンポーネントにも重点が置かれています。
応答性: デフォルトで、Lightning 基本コンポーネントは応答性の高い設計となっています。
イノベーション: Lightning 名前空間は、コンポーネントの開発が積極的に進められている場所です。今後、新しいコンポーネントや改良されたコンポーネントを目にすることがあるかもしれません。
アクセシビリティ: Lightning 基本コンポーネントはアクセシビリティに配慮して作成されています。
クライアント側検証: 該当する場合、Lightning 基本コンポーネントにはクライアント側検証が含まれます。

画像の最適化

可能な場合は、カスタムアイコンの代わりに、(スプライトベースの) SLDS アイコンを使用してください (<lightning-icon> と <lightning-button-icon> を使用してください)。Salesforce には、数百個もの選択可能なアイコンが用意されているため、独自のカスタムアイコンの作成に時間を費やす前に、SLDS で提供されているアイコンを再利用してください。

他の画像を使用する場合、可能であれば、必ず画像サイズをロックしてリフローを回避し、そのサイズで画像を提供します。たとえば、サムネールを表示するために高解像度画像を読み込まないでください。

コンポーネントライフサイクルの表示とリフロー

Lightning Web コンポーネントには、フレームワークで管理されるライフサイクルがあります。フレームワークによって、コンポーネントの作成、DOM への挿入、表示、DOM からの削除が行われます。表示ライフサイクルについて参照し、このライフサイクル中にどのようなことが起こり、いつ、どのメソッドが起動するかを理解してください。コンポーネントが再表示される回数を最小限に抑えます。場合によっては、DOM 領域を特定のサイズにロックして、周辺領域のブラウザーのリフローを回避することが役立つ場合があります。

まとめ

アプリケーションのパフォーマンスは、多種多様な要因によって影響を受けます。この記事で紹介した Lightning Web コンポーネントのパフォーマンスを最適化する技法は、より速く、応答性の高いアプリケーションを構築するのに役立つ一般的なガイドラインです。ご自身のアプリケーションでぜひ試してみてください。

予想時間

トピック

ヘルプをお探しですか?

Agentforce 360 Platform のリソース