ウィジェットの開発に関する一般的なガイドライン
カスタムウィジェットを開発するときは、最適なパフォーマンス、スケーラブルな開発、および優れたユーザーエクスペリエンスのために、次の一般的なガイドラインを念頭に置いてください。
- エンド ユーザーに例を提供する既定の状態を作成する
ウィジェットでは、最初にページに追加されるときにインスタンス オプションが定義されていません。この空の状態のウィジェットは空白で表示され、混乱を招く可能性があります。ウィジェットにいくらかの初期構成を必要とする状況では、必要な構成を管理者に伝えるデフォルトの状態がウィジェットにあることを確認してください。
デモ データを使用してウィジェットを作成することもできます。デモ データは、以下の目的にも使用できます。
- ウィジェットの機能をユーザーに明確に示す。
- ウィジェット エディターでウィジェットをプレビューするときにデータを提供する。(デモ データはデザイナーには表示されません。)
- 可能であればクローンではなくウィジェットを埋め込む
カスタム ウィジェットに既存のウィジェットを埋め込むと、コードをクローンまたは複製しなくても既存の機能を活用できます。その場合も、埋め込みウィジェットにパラメーターを渡して、その動作を制御することができます。
詳細を見る： 既存のウィジェットの埋め込み
- パフォーマンス向上のために大きなデータセットの使用を避ける
データのクエリ、ACL の評価、ビジネスルールの実行、およびデータ処理には時間がかかり、パフォーマンスが低下する可能性があります。ポータルユーザーが必要とするデータの量を決定し、適切な制限とフィルターをスクリプトとクエリに適用します。重要なデータまたは処理を必要とするウィジェットをポータル内の個別のページに分離します。大きなデータセットを使用する次のアイテムは実装しないでください。
- 大量のデータをロードするスクリプト化されたメニューアイテム。これにより、ポータル内のすべてのページのロードが遅くなる可能性があります。
- 添付ファイル [sys_attachment] テーブルの高解像度メディアファイルやフォントなど、サイズの大きいファイルや添付ファイル。
- 自動リフレッシュウィジェット。ウィジェットのクライアントコントローラーが server.update()、 spUtil.update()、 server.refresh()、または spUtil.refresh() を呼び出すたびに、アプリケーションはウィジェットのサーバースクリプトを実行し、データオブジェクトをクライアントに送り返します。
- フィルタリングされていないレコード監視。recordWatch() 関数は、テーブルまたはフィルターの更新を監視し、コールバック関数から値を返します。監視する特定のフィールドにフィルターを追加すると、ウィジェットがサーバーに対して行う呼び出しの数を減らすことができます。コールバック関数に更新があることをクライアントに通知するレコードプロデューサーに対応してウィジェットを更新するタイミングを指定することでも、パフォーマンスを向上させることができます。
setLimit関数なしの GlideRecord クエリを使用するサーバー側スクリプトsetLimit関数は返されるレコードの数を制限し、クエリの応答時間を改善できます。柔軟性を高めるため、ハードコードされた値を割り当てるのではなく、この制限をインスタンス オプションに結びつけることができます (例：gr.setLimit(options.limit || 100))。
詳細：- Six common performance pitfalls in Service Portal and how to avoid them (サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法) [KB0634588]
- spUtil - recordWatch
- GlideRecord setLimit 関数
- 複雑なウィジェットを埋め込む代わりにディレクティブを作成する
埋め込みウィジェットがサーバーから呼び出されると、そのウィジェットに関連付けられたすべてのスクリプトが返されます。ウィジェットのサブセクションのみが必要な場合、ウィジェット全体を埋め込むと不要なオーバーヘッドが発生します。代わりに、ディレクティブを使用して軽量のコードをウィジェット間で共有します。ディレクティブは、たとえば UI コンポーネントをビルドする場合に便利です。サーバー側とクライアント側の機能を備えた複雑なコンポーネントは、ウィジェットとして残すことをお勧めします。埋め込みウィジェットの代わりにディレクティブを使用するのは、以下の場合です。
- スコープやカスタム スコープの動作を複数のウィジェットで共有する。
- ウィジェットの再利用可能な軽量のサブセクションを共有する。
- リストやアバターなどの共通の UI 機能を共有する。
- ウィジェットの動作を強化する。
- サービスやファクトリを使用してデータの共有と状態の保持を行う
データ サービスとファクトリは、サーバーを複数回呼び出さなくてもウィジェット内で状態を維持および保持できるため、以下のことが可能になります。
- レコードやフィルターを変更するときにウィジェットの同期状態を保つ。
- ウィジェット間でデータを共有する。
- よりパフォーマンスの高いウィジェットを開発する。
- 公開/登録サービスを使用してイベントを処理する
DOM で $broadcast を使用しないでください。$broadcast は、イベント名をすべての子スコープに送信して、登録されたリスナーに通知するため、$rootScope グローバル オブジェクトの使用が必要になり、コールにコストがかかる可能性があります。
代わりに、公開/登録サービスを使用してイベントを処理します。公開/登録サービスを使用すると、コールバック ハンドラーを介してウィジェット間に明確な関係が形成されます。このモデルでは、イベントの状態をより適切にコントロールできます。
- REST コールまたは
server.getを使用してサーバーからデータを取得する server.update()を呼び出すと、ウィジェット全体がサーバーから返されます。ウィジェットに相違するコード パスが含まれている場合、サーバー更新コールを複数回行うとパフォーマンスに影響する可能性があります。原則として、サーバー スクリプトを使用してウィジェットの初期状態を設定します。その後の更新では、インスタンスでスクリプトインクルードを呼び出すスクリプト化された REST API を使用します。この手法は以下の結果になります。- ビジネス ロジックが UI 要素から切り離される。
- コードが 1 か所に集められるため、変更を 1 か所で行うことができる。
- ローカライズ、アクセシビリティ、UI を念頭に置いて開発する
ユーザーに最適なエクスペリエンスを作成するには、次のガイドラインに従います。
- モバイル環境でのウィジェットの影響を考慮します。たとえば、モバイル デバイスに変換されないマウスオーバーや他のイベントを使用しないでください。
- SCSS 変数を使用してアイテムを再利用します。「SCSS 変数」を参照してください。
- 色を使用する場合は変数名を使用します。
- ローカライズ API で翻訳用の文字列をラップします。「ウィジェットの国際化」を参照してください。
- 未使用の Angular プロバイダーをクライアントスクリプトから削除する
- メンテナンスを容易にするために、クライアントスクリプトの関数ステートメントに挿入された未使用の Angular プロバイダーをすべて削除します。
- 使用を避ける <script> tags in HTML templates
- サービスポータル で本番環境の問題が発生する可能性を減らすには、を使用するインラインテンプレートの使用を避けます。 <script> tags in a widget's HTML template. Instead, create a related Angular ng-template record for the widget.