コードコンポーネントのデバッグ

[アーティクル]
06/08/2022

この記事では、開発中にコードコンポーネントロジックをデバッグする方法についての情報を提供します。コードのユニットテストを作成することは、ロジックを Power Apps component framework ランタイムから独立してテストできるようにするためのグッドプラクティスと見なされます。

この記事では、テストハーネスを使用して、Microsoft Dataverse にデプロイした後にコードコンポーネントをデバッグする方法を示します。

コードコンポーネントのデバッグ

注意

エンティティとテーブルの違いがわかりませんか？ Microsoft Dataverse で「開発者: 用語を理解する」を参照してください。

ブラウザのテストハーネスを使用したデバッグ

コードコンポーネントロジックを実装している間、npm start または npm start watch がコードコンポーネントをビルドし、新しいブラウザウィンドウでローカルテストハーネスを開きます。このテストハーネスは Microsoft Power Platform CLI の一部であるため、モデル駆動型アプリ、キャンバスアプリ、またはポータルでコードコンポーネントを使用する予定があるかどうかに関係なく同じです。詳細: 最初のコンポーネントを作成する。

注意

npm start を使用する前に、マシンに npm がインストールされているかどうかを確認する必要があります。

次のイメージは、次のような DataSetGridサンプルの npm start watch を使用する際に Visual Studio Code がどのようになるかを示します。

Visual Studio Code のデバッグ。

watch モードでテストハーネスを起動すると、アクションの変化をすばやく確認できます。次のコンポーネントアセットに加えられた変更は、再起動せずにテストハーネスに自動的に反映されます。

index.ts ファイル。
index.ts にインポートされたモジュール (node_modules を除く)。
ControlManifest.Input.xml ファイルにリストされているすべてのリソース。たとえば、css/DataSetGrid.css または strings/DataSetGrid.1033.resx

これらのファイルのいずれかに変更を加えると、Change detectedメッセージが表示され、ブラウザは更新されたコードでリロードします。

変更が検出されました。

次の画像は、新しいブラウザウィンドウで開いたテストハーネスを示しています。

テストハーネス 1

上の画像が示すように、ブラウザウィンドウが開き、4 つの領域が表示されます。コードコンポーネントは左側のペインにレンダリングされますが、右側のペインには、デバッグされるコンポーネントのタイプに応じて 3 つのセクションがあります。

コンテキスト入力 はすべてのコードコンポーネントタイプについて表示されます。
- フォームファクター: フォームファクターを指定する方法、フォームファクター (Web、タブレット、電話) でコードコンポーネントをテストする方法を提供します。これは、コードコンポーネントが、コンポーネントのロード場所に応じてレイアウトを変更する場合に役立ちます。 context.client.getFormFactor() を使用して、コード内のフォームファクターを検出できます。
- コンポーネントコンテナの幅と高さ: 最初は、幅と高さは空です。これにより、コードコンポーネントがコンテナ内に配置されdiv、これは幅も高さ CSS スタイルセットもありません。幅または高さを指定すると、コンテナdivは、コードコンポーネントが使用可能なスペースにどのように適応するかを確認できるように、寸法が制限されます。正確な動作はテストハーネスの動作とは異なるため、一度展開すると Power Apps 内部のコードコンポーネントの動作を注意深くテストする必要があります。さらに、updateView メソッドで context.mode.allocatedHeight``context.mode.allocatedWidth を受け取りたい場合は、コンポーネントは context.mode.trackContainerResize(true) を呼び出す必要がありますが、テストハーネスは、この呼び出しに関係なく、常に高さと幅を提供します。詳細: trackContainerResize。
注意

テストハーネスを使用する場合、allocatedWidth と allocatedHeight は数値ではなくテキストとして提供されます。
データの入力 は、マニフェストファイルで定義されている、すべてのプロパティと種別あるいは種別グループを表示する対話型の UI です。この領域の内容は、ControlManifest.Input.xml で定義されているプロパティとデータセットによって異なり、テスト目的でモックデータを提供できます。
出力はコンポーネントの getOutputs メソッドが呼ばれるたびに出力をレンダーします。

注意

ControlManifest.Input.xml ファイルの修正または新規プロパティを作成する場合は、それらを入力セクションにその他のプロパティやデータベースが表示される前にデバッグプロセスを再起動する必要があります。コマンドラインで実行中のプロセスで Ctrl + c を使用してこれを行い、npm start watch を再び実行します。

重要

npm start と npm start watch を使うと、開発とデバッグ用に最適化されたコードコンポーネントをビルドします。このコードは通常、Microsoft Dataverse にデプロイされます。詳細: コードコンポーネントアプリケーションのライフサイクル管理。

擬似データを使用してコードコンポーネントをテストします。

ControlManifest.Input.xml で property 要素を持つコンポーネントに対しては、データ入力 セクションには、各値の入力ボックスが表示されます。
データセット タイプのコンポーネントの場合、それぞれのデータセット要素に対してテストデータを含む CSV ファイルを読み込むことができます。ご利用の環境から直接、 .csv 形式のファイルを手動で作成またはエクスポートします。 CSV ファイルの読み込みが完了したら、ControlManifest.Input.xml で定義されたプロパティセットを CSV ファイルの列にバインドします。これを行うには、以下のように各プロパティの列を選択します:
ControlManifest.Input.xml ファイルで定義されているプロパティをまったくもっていない場合は、すべての列が自動的にテストハーネスに読み込まれます。次に、ソース CSV の各列について、以下に示すように、コードコンポーネントに提供された使用するデータ型を割り当てることができます。

注意

CSV サンプルデータセットを読み込むときは、データがロードされる前に 適用する を選択する必要があります。データセットにプロパティセット要素が定義されている場合は、適用する を選択する前に、それぞれを CSV の列にマップする必要があります。これらの設定は記憶されておらず、テストハーネスの再ロード後、コードを変更するたびに設定する必要があります。

テストハーネスを使用する際の一般的な制限

テストハーネスは単純なコードコンポーネントのテストに適していますが、次のシナリオでは、テストハーネスを使用してより複雑なコードコンポーネントをテストできない場合があります。

テストハーネス データ入力 セクションを介してプロパティが変更された場合、updateProperties 配列は設定されません。
ControlManifest.Input.xml の feature-usage セクションに記載されている機能を使用する。たとえば、context.WebApi.* メソッドは、テストハーネス内から例外をスローします。
データセット上でページング、並べ替え、フィルタリング API を使用すると、テストハーネス内から例外をスローします。
選択やルックアップなど、追加のメタデータを提供する複雑なデータ型バインディングの使用。選択列の場合、テストハーネスは、最小限のメタデータで 3 つの簡単な選択を提供します。
モデル駆動型アプリは、フィールドレベルのセキュリティ、読み取り専用の動作、データセット選択 API、モデル駆動型アプリのコマンドバーとの統合などを指定します。
ナビゲーションメソッドやユーティリティメソッドなどの他のコンテキスト API。

これらのシナリオをテストするには、最初にコードコンポーネントをデプロイし、Fiddler を使用して Dataverse へデプロイした後のデバッグで説明されている手法を使用してテストする必要があります

ブラウザ開発ツールを使用してコードコンポーネントをデバッグする

最新のブラウザには、HTML、CSS、現在のページにロードされた JavaScript を検査できる開発者ツールのセットが組み込まれています。キーボードショートカット Ctrl+Shift+I を使用して、これらの開発者ツールにアクセスできます。 F12 キーを使用して、開発者ツールを開くための一般的なキーボードショートカットでもありますが、これは アプリをダウンロード キーボードショートカットすでに使用されているため Power Apps Studio 内部では機能しません。

webpack を使用したバンドル

TypeScript を使用してコードコンポーネントを作成する場合、コードは、バンドルされたコードコンポーネントの出力に出力される JavaScript とは異なって見える可能性があります。 npm start や npm start watch を実行する場合、(pac pcf init を実行することで packages.json に追加された) pcf-scripts モジュールは、Web パックを使用して、複数の TypeScript ファイルを out フォルダ内の 1 つの bundle.js ビルドします。このフォルダには、マニフェスト自体を含むが、代わりに単に ControlManifest.xml として名づけられている ControlManifest.Input.xml によって参照される他のリソース (たとえば、html/css) も含まれます。

JavaScript のターゲット標準 (ES5 など) でサポートされていないインポート / エクスポートや非同期 / 承認などの最新の TypeScript 言語機能を使用する場合、ビルドプロセスはこれらの言語機能を使用せずに TypeScript を JavaScript にトランスパイルします。開発ビルドの一部として出力されるソースマップは、TypeScript のブレークポイントの場所を JavaScript の対応する行にマップできるように、開発者ツールに情報を提供します。同様に、例外が発生したり、コードをステップ実行したりすると、基になるトランスパイルされた JavaScript ではなく、元の TypeScript 行が表示されます。

バンドルのもう 1 つの機能は、npm install を使って外部モジュールを含める時に、ビルドプロセスは必要なモジュールを、関連する node_modules ディレクトリのコンテンツを使用するコードコンポーネント bundle.js に追加します。このため、使用する外部モジュールは、バンドルできるようにパッケージ化する必要があります。詳細: ベストプラクティス: モジュールのインポート。

注意

ソースマップは、ビルトイン開発モードを実行した場合にのみ出力され、本番ビルドよりもはるかに大きなファイルになります。このため、開発目的でビルドした後にコードコンポーネントをデプロイすることはお勧めしません。詳細: アプリケーションライフサイクル管理 (ALM)。

開発者ツールをコードコンポーネントと使用する

このセクションでは、Microsoft Edge 開発者ツール内部のコードコンポーネントをデバッグする方法について説明します。

次のいずれかを使用して、コードコンポーネントをブラウザセッションにロードします。
1. npm start watch を使用してテストハーネスを開始します。
2. モデル駆動型、キャンバスアプリ、またはポータルブラウザセッションにロードされたコードコンポーネントのローカル開発ビルド。コードコンポーネントの開発ビルドを Dataverse サーバーにデプロイする必要はありません、代わりに、Fiddlerを使用した Microsoft Dataverse へのデプロイ後のデバッグで説明されているように Fiddler AutoResponders を使用できます。
Ctrl + Shift + I を選択して、開発者ツールを開きます。
開発者ツールパネル内の ソース タブを選択します。
Ctrl + P を使用して、ファイルを開く コマンドパレットを表示します。 省略記号 メニューから ファイルを開く を選択することもできます。
コントロールの名前を入力します (これは、pac pcf init で使用したコントロールの名前になります)。
リストされているものと一致する中から webpack://pcf_tools_652ac3f36e1e4bca82eb3c1dc44e6fad/./DataSetGrid/index.ts のようなファイルを選択します
updateView 関数を配置し、最初の行にブレークポイントを設定します。
コードコンポーネントにバインドされているプロパティを変更します。テストハーネスでは、これはプロパティパネルを使用する、または Power Apps 内部で行うことができ、バインドされたプロパティまたはデータセットに変更を加えることができます。これにより、updateView への呼び出しがトリガーされます。
ブレークポイントがヒットしたことがわかり、コードを調べることができます。
要素タブを使用してコンポーネントによって作成された HTML 要素と CSS を調べることもできます。関心のある特定の相互作用のセット (ルートコンテナ要素) がある場合は、コンテキストメニュー (ルート要素が選択されている間) >休憩 > サブツリーの変更 を使用して HTML Dom 要素にブレークポイントを設定できます

ES5 と ES6

現在、規定では、コードコンポーネントは ES5 JavaScript にトランスパイルするように構成されているため、古いブラウザーがサポートされます。あなたのプロジェクトの target を tsconfig.json から ES6 に設定することで古いブラウザをサポートする必要がない場合は、対称を ES6 に変更できます。

{
  "extends": "./node_modules/pcf-scripts/tsconfig_base.json",
  "compilerOptions": {
    "target": "ES6",
    "typeRoots": ["node_modules/@types"]
  }
}

注意

現時点では、ソースマップは、ソースからではなく、各 TypeScript ファイルの TypeScript トランスパイル出力から生成されます。 ES5 が対象の場合、ES6 言語機能 (クラスなど) が削除されるため、ソースマップが読みにくくなります。 ES6 のサポートが追加されるまで、ES5 を出力する必要がある場合でも、tsconfig.json を更新してソースマップが元の TypeScript に近くなるように、開発中に ES6 をターゲットにします。 ES5 を出力する必要がある場合は、本番デプロイ用のコードコンポーネントをビルドする前に、ES5 を元に戻すことを忘れないでください。

Microsoft Dataverse にデプロイした後のデバッグ

モデル駆動型アプリ、キャンバスアプリ、またはポータルのコンテキスト内でロジックを完全にテストするには、最初にコードコンポーネントを Microsoft Dataverse にデプロイして構成します。次に、Fiddler の AutoResponder 機能または requestly を使用します。どちらの場合も、コードをデバッグするときに変更を継続的にデプロイすることなく、コードコンポーネントの開発ビルド (ローカルでビルド) をブラウザーに読み込みます。これにより、最初に開発ビルドをデプロイしなくても、開発以外のダウンストリーム環境に対してデバッグすることもできます。

まず、コンポーネントがで展開および構成されていることを確認しますMicrosoft Dataverse。理想的には、コードコンポーネントの本番ビルドのみを Microsoft Dataverse に公開する必要があります。より大きなコードコンポーネントの場合、開発ビルドを公開するとエラー Web リソースのサイズが大きすぎますが発生する可能性があります。コードコンポーネントの bundle.js をローカルで構築されたバージョンにリダイレクトするので、プロパティ PcfBuildMode を運用に設定することで pac pcf push を使用する際、自分の .pcfproj ファイルを更新して運用モードで常にビルドできます。

<PropertyGroup>
  <Name>ReactStandardControl</Name>
  <ProjectGuid>0df84c56-2f55-4a80-ac9f-85b7a14bf378</ProjectGuid>
  <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
  <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

Fiddler の使用

Fiddler を使用してコードコンポーネントをデバッグするには:

Fiddler Classic をダウンロードおよびインストールする
Fiddler を開いて、メニューバーから、ツール に移動し、オプション を選択します。
HTTPS トラフィックをキャプチャして、復号化するように、ダイアログボックスで HTTPS タブを選択して、HTTPS 接続をキャプチャ および HTTPS トラフィックを復号化 チェックボックスをオンにします。
OK を選択して、ダイアログボックスを閉じます。
注意
- この設定を有効にするのが初めての場合は、Fiddler は証明書をインストールするように要求します。新しい設定が有効になるように、証明書をインストールして、Fiddler を再起動します。
- 過去に Fiddler を実行しており、NET::ERR_CERT_AUTHORITY_INVALID エラーが発生した場合は、HTTPS タブで操作ボタンを選択し、すべての証明書をリセット を選択します。これによっても、新しい証明書をインストールするよう要求する複数のプロンプトが表示されます。
右側のパネルで、AutoResponder タブを選択します。
ルールを有効にする と 一致しないリクエストのパススルー がチェックされていることを確認します。
ルールを追加 を選択して最初に入力します。
```
REGEX:(.*?)((?'folder'css|html)(%252f|\/))?YOUR_NAMESPACE\.YOUR_CONTROL_NAME[\.\/](?'fname'[^?]*\.*)(.*?)$
```
ここで、
- YOUR_NAMESPACE - ControlManifest.Input.xml の control.namespace の属性に含まれている pac pcf init に提供した名前空間
- YOUR_CONTROL_NAME - pac pcf init に提供して ControlManifest.Input.xml の control.constructor 属性で設定されたコンポーネント名
このルールは、コードコンポーネントのリクエストに一致することを目的としていますbundle.jsおよび関連リソース（css/html）モデル駆動型アプリとキャンバスアプリの両方で機能するようにPower Apps Studioとプレイヤー。

この例は、次の例のようになります。

もっとシンプルな AutoResponder ルールアプローチを希望する場合、FiddlerAutoResponder を使用して JavaScript Web リソース開発を合理化するを参照してください。
応答するパスとして次のように入力します。
```
C:\COMPONENT_ROOT_FOLDER\out\controls\YOUR_CONTROL_NAME\${folder}\${fname}
```
たとえば、コードコンポーネントのルートフォルダが C:\src\PowerApps-Samples\component-framework\DataSetGrid でコンポーネント名が DataSetGrid の場合、パスは次のようになります。
```
C:\src\PowerApps-Samples\component-framework\DataSetGrid\out\controls\DataSetGrid\${folder}\${fname}
```
保存を選択します。
フィルタ タブを開いて、フィルタを使用する をチェックします。 応答ヘッダー セクションで、応答ヘッダーを設定する にチェックを入れて、以下を提供します。

ヘッダー: Access-Control-Allow-Origin

値: *

Fiddler フィルター。

重要

この手順は、コードコンポーネントがキャンバスアプリにデプロイされた後にデバッグする場合にのみ必要です、なぜなら、リソースは powerapp.com ドメイン下ではなく Blob Storage に格納されているからです。そのため、これらのリソースへのリクエストは、ブラウザによって読み込まれるときにクロスドメインアクセスが必要になります。アクセスする他のサイトのヘッダーを変更するため、デバッグ中は、この Access-Control-Allow-Origin フィルタールールのみを有効化します。

AutoResponder ルールを実行できるようにするには、最初にブラウザのキャッシュをクリアして、コードコンポーネントを含むページをリロードする必要があります。これは、開発者ツール (Ctrl + Shift + I) を開くことで簡単に実行でき、更新 > 空のキャッシュとハードリフレッシュ を右クリックします。

空のキャッシュとハードリフレッシュ。

ローカルマシンからコードコンポーネントをロードしたら、コードに変更を加え (npm start watch の実行中)、ブラウザを更新して、新しくビルドされたバージョンをロードできます。 Fiddler の AutoResponder は、キャッシュ制御ヘッダーを自動的に追加して、ブラウザーによってキャッシュされないようにし、そのため単純な更新で、毎回キャッシュをクリアしなくてもリソースが再ロードされます。

Requestly の使用

Requestly を使用してコードコンポーネントをデバッグするには:

コンピューターでインターネットインフォメーションサービス (IIS) を有効にします。
1. コントロールパネル を開いて、プログラムと機能 > Windows の切り替え 機能のオンかオフを選択します。
2. インターネットインフォメーションサービス (IIS) を有効にする。
3. インターネットインフォメーションサービスを展開し、次のセクションに一覧表示されている Web サーバーコンポーネントが有効になっていることを確認します。
4. OK を選択します。
ISS のセットアップ
1. コンピューターの ISS を開く。
2. 右側のパネル接続で、ツリーを展開して サイト を右クリックします。
3. Web サイトを追加する。
4. サイト 名を設定する。
5. 例えば C:\COMPONENT_ROOT_FOLDER\out\controls\YOUR_CONTROL_NAME\ のように、物理パス をカスタムコンポーネントフォルダに設定します
6. ポート (たとえば任意の数 7777) を設定します。
7. OK を選択します。選択したフォルダが http://localhost:<SELECTED_PORT> でホストされるようになりました
Requestly をダウンロードしてインストールする
ツールへのオンボードに従ってください。
ルールを開いて (https://app.requestly.io/rules) に移動します。
"ホストの置換" ルールを追加します。
1. ルール名のセット。
2. https://[ORG_URL]/[APPLICATION_ID]/webresources/[YOUR_NAMESPACE].[YOUR_CONTROL_NAME]/ で "置換" フィールドを設定する
3. http://localhost:<SELECTED_PORT> で "With" を設定する
4. "要求" を "URL" に [YOUR_NAMESPACE].[YOUR_CONTROL_NAME] を含むと設定する
5. ルールを保存して有効にします。
次に、ブラウザーのキャッシュをクリアして、コードコンポーネントを含むページをリロードする必要があります。これは、開発者ツール (Ctrl + Shift + I) を開くことで簡単に実行でき、更新 > 空のキャッシュとハードリフレッシュ を右クリックします。
ローカルマシンからコードコンポーネントをロードしたら、コードに変更を加え (npm start watch の実行中)、ブラウザを更新して、新しくビルドされたバージョンをロードできます。 Requestly は、キャッシュコントロールヘッダーを自動的に追加して、ブラウザーがキャッシュしないようにします。そのため、単純な更新で、毎回キャッシュをクリアしなくてもリソースが再ロードされます。

Power Apps Component Framework API の参照
 Power Apps Component Framework の概要
 アプリケーションライフサイクル管理 (ALM)
最初のコンポーネントを作成する

注意

ドキュメントの言語設定についてお聞かせください。簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。個人データは収集されません (プライバシーステートメント)。

コード コンポーネントのデバッグ

ブラウザのテスト ハーネスを使用したデバッグ

擬似データを使用してコード コンポーネントをテストします。

テスト ハーネスを使用する際の一般的な制限

ブラウザ開発ツールを使用してコード コンポーネントをデバッグする