Power Apps Component Framework を使用して作成されたコード コンポーネントのベスト プラクティスとガイダンス

これらのPower Appsコンポーネント フレームワークのベスト プラクティスを使用して、使いやすさ、サポート性、パフォーマンスを向上させるコード コンポーネントの開発、デプロイ、保守を行います。 このガイダンスでは、次の領域について説明します。

  • Power Apps コンポーネント フレームワーク
  • マイクロソフト パワー アプリ
  • TypeScript および JavaScript
  • HTML ブラウザのユーザー インターフェイスの開発
  • Azure DevOps/GitHub

この記事では、コード コンポーネントを開発する専門家に向けて、確立されたベスト プラクティスとガイダンスを概説しています。 この記事では、これらのツールやヒントがもたらす使いやすさ、サポート性、パフォーマンスの向上をコード コンポーネントで活用できるように、それぞれの利点を説明することを目的としています。

Power Apps コンポーネント フレームワーク

このセクションには、Power Apps Component Framework 体に関連するベスト プラクティスとガイダンスが含まれています。

開発ビルドを Dataverse にデプロイすることは避ける

運用環境または開発モードでコード コンポーネントをビルドします。 パフォーマンスに悪影響を及ぼし、サイズが原因でデプロイがブロックされる可能性があるため、開発ビルドを Dataverse にデプロイすることは避けます。 後でリリース ビルドをデプロイする予定がある場合でも、自動リリース パイプラインがないと、再デプロイを忘れがちです。 詳細については、「 カスタム コントロールのデバッグ」を参照してください。

サポートされないフレームワーク メソッドを使用しない

ComponentFramework.Contextに存在する文書化されていない内部メソッドは使用しないでください。 これらのメソッドは機能する場合もありますが、サポートされていないため、将来のバージョンでは機能しなくなる可能性があります。 ホスト アプリケーションの HTML ドキュメント オブジェクト モデル (DOM) にアクセスするコントロール スクリプトの使用はサポートされていません。 コード コンポーネントの境界外にあるホスト アプリケーションの DOM の部分は、予告なしに変更される場合があります。

init メソッドを使用して、ネットワークに必要なリソースを要求する

ホスティング コンテキストは、コード コンポーネントを読み込むときに、最初に init メソッドを呼び出します。 updateView メソッドまで待機する代わりに、このメソッドを使用してメタデータなどのネットワーク リソースを要求します。 リクエストが返される前に updateView メソッドが呼び出されると、コード コンポーネントはこの状態を処理し、視覚的な読み込みインジケーターを表示する必要があります。

destroy メソッド内でリソースをクリーンアップする

コード コンポーネントがブラウザーの DOM から削除されると、ホスティング コンテキストが destroy を呼び出します。 destroy メソッドを使用して、WebSocketsを閉じ、コンテナー要素の外部に追加したイベント ハンドラーを削除します。 React を使用している場合は、ReactDOM.unmountComponentAtNode メソッドの内部の destroy を使用します。 この方法でリソースをクリーンアップすると、特定のブラウザー セッション内でのコード コンポーネントの読み込みとアンロードによって発生するパフォーマンスの問題を防ぐことができます。

データセット プロパティを更新するための不要な呼び出しを回避する

コード コンポーネントのタイプがデータセットの場合、バインドされたデータセット プロパティが refresh メソッドを公開することで、ホスティング コンテキストがデータをリロードします。 不必要にこのメソッドを呼び出すと、コード コンポーネントのパフォーマンスに悪影響を与えます。

notifyOutputChanged の呼び出しを最小限に抑える

状況によっては、UI コントロール (キー押下やマウス移動イベントなど) を各呼び出し notifyOutputChangedに更新することは望ましくありません。 notifyOutputChanged の呼び出しが多いほど、必要以上に多くのイベントが親コンテキストに伝達されます。 代わりに、コントロールがフォーカスを失ったとき、またはユーザーのタッチまたはマウス イベントが完了したときにイベントの使用を検討してください。

API の空き状況の確認

異なるホスト (モデル駆動型アプリ、キャンバス アプリ、ポータル) のコード コンポーネントを開発するときは、プラットフォームでサポートとして使用している API の可用性を常に確認してください。 たとえば、context.webAPI はキャンバス アプリで使用できません。 個々の API の可用性については、Power Apps component framework API リファレンス を参照してください。

updateView に渡される一時的に null のプロパティ値管理します

データの準備ができていない場合、updateView メソッドに渡される値は null になります。 コンポーネントはこの状況を考慮し、データが null である可能性があること、また後続の updateView サイクルに更新された値が含まれる可能性があることを想定する必要があります。 updateView標準React コンポーネントの両方で利用可能です。

モデル駆動型アプリ

このセクションには、モデル駆動型アプリ内のコード コンポーネントに関連するベスト プラクティスとガイダンスが含まれています。

formContext と直接やり取りしないでください

クライアント API を使用した経験がある場合は、formContext にアクセスして、属性、コントロールにアクセスし、saverefreshsetNotification などの API メソッドを呼び出すことができます。 コード コンポーネントは、モデル駆動型アプリ、キャンバス アプリ、ダッシュボードなどのさまざまな製品で動作することが期待されるため、 formContextに依存することはできません。

回避策は、コード コンポーネントを列にバインドし、OnChange イベントハンドラーをその列へ追加する方法です。 コード コンポーネントは列の値を更新でき、OnChange イベント ハンドラーは formContext にアクセスできます。 将来的には、列構成を追加せずにコントロールの外部で変更を伝達するために使用できるカスタム イベントのサポートを追加する予定です。

WebApi への呼び出しのサイズと頻度を制限する

context.WebApi メソッドを使用する場合は、呼び出しの数とデータ量の両方を制限します。 WebApiを呼び出すたびに、ユーザーの API エンタイトルメントとサービス保護の制限にカウントされます。 レコードに対して CRUD 操作を実行する場合は、ペイロードのサイズを検討してください。 一般に、要求のペイロードが大きいほど、コード コンポーネントは遅くなります。

キャンバス アプリ

このセクションには、キャンバス アプリ内のコード コンポーネントに関連するベスト プラクティスとガイダンスが含まれています。

画面上のコンポーネント数を最小限に抑える

キャンバス アプリにコンポーネントを追加するたびに、レンダリングに限られた時間がかかります。 コンポーネントを追加するたびにレンダリング時間は長くなります。 開発者パフォーマンス ツールを使用して画面に追加するときに、コード コンポーネントのパフォーマンスを慎重に測定します。

現在、各コード コンポーネントには、Fluent UI や React などの共有ライブラリの独自のライブラリがバンドルされています。 同じライブラリの複数のインスタンスを読み込んでも、これらのライブラリは複数回読み込まれません。 ただし、複数の異なるコードコンポーネントを読み込むと、ブラウザはこれらのライブラリの複数のバンドルバージョンを読み込みます。 将来的には、これらのライブラリを読み込んでコード コンポーネントと共有することができます。

メーカーがコード コンポーネントのスタイルを設定できるようにする

アプリ メーカーがキャンバス アプリ内からコード コンポーネントを使用する場合、アプリの他の部分と一致するスタイルを使用すると便利です。 入力プロパティを使用して、色やサイズなどのテーマ要素のカスタマイズ オプションを使用できるようにします。 Microsoft Fluent UI を使用する場合は、これらのプロパティをライブラリが提供するテーマ要素にマップします。 将来的には、テーマ サポートがコード コンポーネントに追加され、プロセスが簡単になります。

キャンバス アプリのパフォーマンスのベスト プラクティスに従う

キャンバス アプリは、アプリとソリューション チェッカー内から幅広いベスト プラクティスを提供します。 コード コンポーネントを追加する前に、アプリがレコメンデーションに従っているかを確認してください。 詳細については、以下を参照してください。

TypeScript および JavaScript

このセクションには、コード コンポーネント内の TypeScript および JavaScript に関連するベスト プラクティスとガイダンスが含まれています。

ES5 と ES6

既定では、コード コンポーネントは ES5 をターゲットにして古いブラウザーをサポートします。 これらの古いブラウザーをサポートしない場合は、 pcfproj フォルダーの tsconfig.json内のターゲットを ES6 に変更します。 詳細については、 ES5 と ES6 を参照してください。

モジュールのインポート

SCRIPT タグを使用して読み込む必要があるスクリプトを使用する代わりに、コード コンポーネントに必要なモジュールを常にバンドルします。 たとえば、サンプルでページへの<script type="text/javascript" src="somechartlibrary.js></script>の追加が示されているMicrosoft以外のグラフ API を使用する場合、この方法はコード コンポーネント内ではサポートされていません。 必要なすべてのモジュールをバンドルすると、コード コンポーネントが他のライブラリから分離され、オフライン モードでの実行もサポートされます。

コンポーネント マニフェストでライブラリ ノードを使用したコンポーネント間での共有ライブラリのサポートはまだサポートされていません。

コード コンポーネント用に ESLint を構成する

Linting は、ツールがコードをスキャンして潜在的な問題を探す場所です。 pac pcf init が使用するテンプレートは eslint モジュールをプロジェクトにインストールし、.eslintrc.json ファイルを追加することで構成します。 Eslint は、TypeScript および React のコーディング スタイルを構成する必要があります。 また、これらの問題の一部を可能な限り自動的に修正することもできます。 構成するには、次のコマンドを使用します。

npx eslint --init

次に、指示が出たら次の質問に答えます。

  • ESLint をどのように使用したいですか。 回答: 構文をチェックし、問題を見つけ、コード スタイルを適用する

  • プロジェクトでは、どのタイプのモジュールを使用していますか。 回答: JavaScript モジュール (インポート/エクスポート)

  • プロジェクトで使用しているフレームワークはどれですか。 回答: React

  • あなたのプロジェクトでは TypeScript を使用していますか。 回答: はい

  • コードはどこで実行されますか。 回答: ブラウザー

  • プロジェクトのスタイルをどう定義しますか。 回答: スタイルに関する質問に答える

  • 希望する構成ファイルの形式は。 回答: JSON (この答えは、既存の .eslintrc.json が更新されます)

  • どのスタイルのインデントを使用しますか。 回答: スペース (このインデントスタイルは Visual Studio Code のデフォルトです)

  • 文字列にはどの引用符を使用しますか。 回答: シングル

  • どの改行コードを使いますか。 回答: Windows (この行の編集は Visual Studio Code のデフォルト CRLF 行編集スタイルです。)

  • セミコロンが必要ですか。 回答: はい

この構成は、特定のニーズに合わせてカスタマイズできます (React を使用していない場合など)。 詳細については、「 ESLint の概要」を参照してください。

eslint を使用するには、package.json にスクリプトを追加する必要があります。

 "scripts": {
    ...
    "lint": "eslint MY_CONTROL_NAME --ext .ts,.tsx",
    "lint:fix": "npm run lint -- --fix"
  }

eslint スクリプトは、コードを含むフォルダーを受け入れます。 MY_CONTROL_NAMEpac pcf init を呼び出す際に使用されるコードコンポーネントと同じ名前に置き換えます。

コマンドラインで以下を使用できるようになりました:

npm run lint:fix

このコマンドにより、プロジェクト内のコードが整理され選択したスタイルに統一し、後で解決できる問題も報告されます。

ESLint は、テンプレート コードに関する最初の問題 (空のコンストラクターなど) を指摘します。 インライン コメントを追加すると、ESLint が // eslint-disable-next-line @typescript-eslint/no-empty-function などのルールを除外します

さらに、以下を .eslintrc.json に追加すると、無視するファイル (たとえば、自動生成されたインターフェイス) を追加できます:

"ignorePatterns": ["**/generated/*.ts"]

詳細については、 構成ファイルの ignorePatterns を参照してください。

ヒント

プロジェクトの.eslintrc.json ファイルを使用するVisual Studio Code拡張機能をインストールすると、検出された問題のコードが強調表示されます。IDE 内で直接修正することもできます。 詳細については、「Visual Studio Codeでの拡張機能の管理」を参照してください。

HTML ブラウザーのユーザー インターフェイスの開発

このセクションには、HTML ブラウザー UI 開発のベスト プラクティスとガイダンスが含まれています。

Microsoft Fluent UI React を使用する

Fluent UI React は、公式の オープン ソース React で、幅広いマイクロソフト製品にシームレスに適合するエクスペリエンスを構築するように設計されたフロントエンド フレームワークです。 Power Apps自体は Fluent UI を使用するため、他のアプリと一貫性のある UI を作成できます。

Fluent からのパス ベースのインポートを使用して、バンドル サイズを縮小します

現在、 pac pcf init で使用されるコード コンポーネント テンプレートでは、ツリーシェイクは使用されません。 ツリーシェイキングとは、webpack がインポートしたものの使用されていないモジュールを検出して削除する処理です。 次のコマンドを使用して Fluent UI からインポートする場合は、ライブラリ全体をインポートしてバンドルします。

import { Button } from '@fluentui/react'

ライブラリ全体のインポートとバンドルを回避するには、パスベースのインポートを使用し、明示的なパスを使用して特定のライブラリ コンポーネントをインポートします。

import { Button } from '@fluentui/react/lib/Button';

特定のパスを使用すると、開発ビルドとリリース ビルドの両方でバンドル サイズが小さくなります。

compilerOptions セクション内で次のモジュール構成を使用するようにtsconfig.jsonを更新することで、ツリーシェイク (リリースビルドと実稼働ビルドにのみ影響します) を利用できます。

"module": "es2015",
"moduleResolution": "node"

詳細: Fluent UI - 高度な使用法

React レンダリングを最適化する

React を使用する場合は、コンポーネントのレンダリングを最小限に抑えるための React 固有のベスト プラクティスに従ってください。 この方法により、UI の応答性が向上します。 次の一覧には、いくつかのベスト プラクティスが含まれています。

  • バインドされたプロパティまたはフレームワークの側面の変更で UI に変更を反映させる必要がある場合は、updateView メソッド内のReactDOM.renderのみを呼び出します。 updatedProperties を使用して、何が変更されたかを確認します。
  • 可能な場合は、 PureComponent (クラス コンポーネントを含む) または React.memo (関数コンポーネントを含む) を使用して、入力プロパティが変更されない場合にコンポーネントの不要な再レンダリングを回避します。
  • 規模の大きな React コンポーネントの場合は、UI を小さなコンポーネントに分解してパフォーマンスを向上させます。
  • render 関数内で矢印関数と関数バインドを使用しないでください。 これらのプラクティスでは、レンダリングごとに新しいコールバック クロージャが作成され、親コンポーネントがレンダリングされるときに子コンポーネントが常に再レンダリングされます。 代わりに、コンストラクターで関数バインディングを使用するか、クラス フィールドの矢印関数を使用してください。 イベントの処理 - React を参照する。

アクセシビリティの確認

キーボード専用およびスクリーン リーダーのユーザーがコード コンポーネントを使用できるように、コード コンポーネントにアクセスできることを確認します。

  • マウスイベントやタッチイベントに代わるキーボードナビゲーションを提供します。 たとえば、コンポーネントにドロップダウン リストが用意されている場合は、ユーザーが Tab キー を使用してフォーカスを設定し、方向キーを使用してオプション内を移動できることを確認します。
  • スクリーン リーダーがコード コンポーネントのインターフェイスを正確に表現できるように、 alt 属性と ARIA (アクセシビリティ対応リッチ インターネット アプリケーション) 属性が設定されていることを確認します。 Microsoft Fluent UI ライブラリでは、多くのコンポーネントがすでにアクセス可能であり、スクリーン リーダーと互換性があるため、この属性を使うことが簡単です。
  • 最新のブラウザ開発者ツールには、アクセシビリティを検査する優れたツールが含まれています。 これらのツールを使用して、コード コンポーネントに関する一般的なアクセシビリティの問題を検索します。

詳細については、「Power Apps でアクセシビリティ対応のキャンバス アプリを作成する」を参照してください。

常に非同期ネットワークの呼び出しを使用する

ネットワーク呼び出しを行うときは、この要求によってアプリが応答を停止し、パフォーマンスが低下するため、同期ブロック要求を使用しないでください。 詳細については、「 HTTP および HTTPS リソースを非同期的に操作する」を参照してください。

複数のブラウザーに対応したコードを記述する

モデル駆動型アプリ、キャンバス アプリ、ポータルはすべて、複数のブラウザをサポートしています。 最新のすべてのブラウザーでサポートされている手段のみを使用し、対象ユーザーが使用する一般的なブラウザーでテストしてください。

コード コンポーネントは、複数のクライアントと画面形式をサポートする計画が必要です

コード コンポーネントは、複数のクライアント (モデル駆動型アプリ、キャンバス アプリ、ポータル) および画面形式 (モバイル、タブレット、Web) でレンダリングできます。 モデル駆動型アプリで使用する場合、データセット コード コンポーネントは、メイン フォーム グリッド、関連するレコード グリッド、サブグリッド、またはダッシュボードに配置できます。 キャンバス アプリで使用する場合、コード コンポーネントは、アプリ 作成者が提供する構成を使用して動的にサイズを変更する応答性の高いコンテナー内に配置できます。

  • trackContainerResizeを使用することで、コード コンポーネントは使用可能な幅と高さの変更に対応できます。 場合によっては、このプロパティを設定すると、使用可能な領域に合った別の UI がレンダリングされます。 allocatedHeightallocatedWidthgetFormFactorと組み合わせて、コード コンポーネントがモバイル、タブレット、または Web クライアントで実行されているかどうかを判断できます。 詳細については、この 選択肢選択のチュートリアルを参照してください。
  • setFullScreenを実装することで、ユーザーは領域が制限されている使用可能な画面全体を使用するように拡張できます。 詳細については、「 キャンバス アプリのグリッド コンポーネント」を参照してください。
  • コード コンポーネントが指定されたコンテナー サイズで有意義なエクスペリエンスを実現できない場合は、機能を適切に無効にして、ユーザーにフィードバックを提供する必要があります。

常にスコープ設定されている CSS ルールを使用する

CSS を使用してコード コンポーネントのスタイルを実装する場合は、CSS のスコープをコンポーネントに設定してください。 コンポーネントのコンテナー DIV 要素に適用される自動的に生成された CSS クラスを使用します。 CSS のスコープをグローバルに設定すると、コード コンポーネントがレンダリングされるフォームまたは画面の既存のスタイル設定が解除される可能性があります。 サードパーティの CSS フレームワークを使用する場合は、そのフレームワークの名前空間付きバージョンを使用するか、手動または CSS プリプロセッサを使用して、名前空間にフレームワークをラップします。

たとえば、名前空間が SampleNamespace され、コード コンポーネント名が LinearInputComponentされている場合は、次を使用してカスタム CSS ルールを追加します。

.SampleNamespace\.LinearInputComponent rule-name

Web ストレージ オブジェクトは使用しないでください

コード コンポーネントは、データを保存するために window.localStoragewindow.sessionStorage のような HTML Web ストレージ オブジェクトを使用しないでください。 ユーザーのブラウザーまたはモバイル クライアントにローカルに格納されているデータは安全ではなく、確実に使用できるとは限りません。

ALM、Azure DevOps、およびGitHub

ALM、Azure DevOps、およびGitHubを使用したコード コンポーネントのベスト プラクティスについては、コード コンポーネント アプリケーション ライフサイクル管理 (ALM) に関する記事を参照してください。