クライアントスクリプトの記述に関するベストプラクティス

9 分

クライアントスクリプトの開発は、熟練した JavaScript 開発者にとっては簡単な作業であるようにも思えますが、その使用について検討する際には、ベストプラクティスを考慮することが重要です。開発者は、ユーザーがその他の手段でデータにアクセスできることに気付いていないことがよくあります。たとえば、データのインポートまたはエクスポート、メーカースタジオ、キャンバスアプリ、サードパーティのデスクトップアプリ、シェルスクリプトなどを使用できる場合もあります。クライアントスクリプトを使用して、クライアント側で起きる UI の問題を解決したり、モデル駆動型アプリのユーザーエクスペリエンスを強化したりする必要があります。セキュリティの保護や、すべての問題を解決することを目的とするものではありません。 Dataverse プラグインのように、クライアント側のアプローチをサーバー側のアプローチと組み合わせることで、すべてのアクセスポイントにビジネス要件を実装しなければならないことがよくあります。

ソリューションチェッカーを使用する

ソリューションチェッカーを使用すると、ソリューションの静的分析チェックを、一連のベストプラクティスルールに従って実行して、問題となり得るパターンをすばやく特定することができます。ソリューションチェッカーでは、クライアントスクリプトに使用される JavaScript もチェックされます。パフォーマンス、安定性、信頼性の問題など、ユーザーエクスペリエンスの低下を招く問題が起きた場合にそれを特定することができます。また、非推奨のメソッドが使用されていれば、それを検出することもできます。これを定期的に実行することで、ソリューションをユーザーにリリースする前に問題をプロアクティブに特定して修正することができます。ソリューションチェッカーを Maker Portal からオンデマンドで実行したり、自動ビルドプロセスの一環として実行したりすることができます。こうした自動化により、定期的な実行が可能となり、現行のアプリケーションライフサイクル管理プロセスに、このチェックを含めることができます。

ソリューションチェッカーの使用について詳しくは、製品ドキュメントの「ソリューションチェッカーを使用して Power Apps のアプリを評価する」を参照してください。

ビジネスルールとクライアントスクリプトの比較

ビジネスルールは、モデル駆動型アプリケーションで使用できる機能です。これは、特定の要件や条件に基づいて、頻繁に必要とされるアクションをユーザーがフォーム上で実行できるようにするものです。具体的には、ビジネスルールでは次のタスクを実行できます。

フィールドの値を設定する
フィールド値をクリアする
フィールド要件レベルを設定する
フォームの列コントロールを表示または非表示にする
フォームの列コントロールを有効または無効にする
データを検証し、エラーメッセージを表示する
ビジネスインテリジェンスに基づいてビジネスレコメンデーションを作成する。

ビジネスルールの機能で特に注目すべきなのは、テーブルスコープのルールをロジックにバックエンドで自動的に適用できることです。こうしたスコーピングにより、アクションがユーザーインターフェイス、データインポート、API メソッド呼び出しのどこから実行されようと、アプリの一貫性を確保することができます。これをクライアントスクリプトだけで完全に実現することは不可能です。

提供されているビジネスルールフレームワークは堅牢ですが、シナリオによっては、ビジネスルールによって特定の要件を完全には実装できない場合もあります。その場合は、クライアントスクリプトを使用すれば、ビジネスルールと必要な要件の間のギャップを縮めることができます。ここでは、ビジネスルールよりもクライアントスクリプトを使用したほうが効果的に対応できる可能性がある、一般的な制限事項について説明します。

関連するテーブル内のデータ (取引先企業の基本連絡先の住所など) を参照する必要がある場合は、クライアントスクリプトと Web API を使用する必要があります。

フォーム保存イベントでロジックを実行する必要がある

ビジネスルールは、スコープがテーブルに設定されている場合を除き、フォームの読み込み時とフィールドの変更時にのみ実行されます。フォーム保存イベントでビジネスロジックを実行する必要がある場合は、クライアントスクリプトを使用する必要があります。

複雑な条件

条件に複数の and ステートメントが含まれている場合や、or ステートメントが必要な場合には、ビジネスルールを使用するよりも、クライアントスクリプトにこれらの条件を記述する方が効率的です。

フォームデータの値の消去

フォーム列からデータを消去する操作は、ビジネスルールでは簡単に実現することができません。常に NULL 値を保持する "ダミー" 列を割り当てるなどの回避策も使用できますが、クライアントスクリプトを使用した方が、より洗練された方法で実現できます。

計算列とクライアントスクリプト

計算列は取得時にロジックを実行するため、クライアント側の変更は、フォームを更新するまで計算列の値に反映されません。データをフォームに対して瞬時に更新する場合は、クライアントスクリプトを使用することをお勧めします。多くの場合、計算列、ロールアップ列、プラグインなどを使用するバックエンド実装を補完するためにクライアントスクリプトが使用されますが、この方法であれば、アプリのユーザーエクスペリエンスの一貫性を保つと同時に、バックエンドでのデータの一貫性と整合性も確保することができます。

コーディングの標準とベストプラクティス

次のセクションでは、コーディングのベストプラクティスと標準について説明します。

一意のスクリプト関数名を定義する

多くの場合、作成した関数は、他の多くのライブラリと共にフォーム上にあります。指定した関数と同じ名前の関数が別のライブラリに含まれている場合は、最後に読み込まれた関数がそのフォームで使用されます。競合の可能性を回避するために、一意の関数名を使用するようにしてください。これに関する戦略がまだ決定していない場合は、次の戦略を使用できます。

一意の関数プレフィックス - 一意名の規則に従った一貫性のある名前を使用し、標準の構文を使用して各関数を定義します (次に示すのは例です)。
```
  function MyUniqueName_performMyAction()
  {
  // Code to perform your action.
  }
```

名前空間付きライブラリ - 各関数をスクリプトオブジェクトに関連付けて、関数の呼び出し時に使用する名前空間の種類を作成します (次に示すのは例です)。

  //If the MyUniqueName namespace object isn’t defined, create it.
  if (typeof (MyUniqueName) == "undefined")
     { MyUniqueName = {}; }
     // Create Namespace container for functions in this library;
     MyUniqueName.MyFunctions = {
   performMyAction: function(){
   // Code to perform your action.
   //Call another function in your library
   this.anotherAction();
     },
     anotherAction: function(){
   // Code in another function
    }
  };

機能を使用する際には、完全名を指定します (次に示すのは例です)。

    MyUniqueName.MyFunctions.performMyAction();

ヒント

同じ名前空間にある別の関数内の関数を呼び出す場合は、両方の関数を含んだオブジェクトへのショートカットとして、this キーワードを使用できます。ただし、関数がイベントハンドラーとして使用されている場合、this キーワードは、イベントが発生しているオブジェクトを参照します。

サポートされていないメソッドの使用を回避する

一部のサードパーティのオンラインリソースでは、サポートされていない方法を使用して特定のアクションを実行する方法について提案したり、その例を示したりしている場合がありますが、こうした情報はサポートまたは推奨されていません。これらの方法は、アプリケーションの今後のバージョンでも動作するとは限りません。また、実装が不安定になる可能性があります。また、クライアント API リファレンスドキュメントの公式ドキュメントに記載されていないメソッドが、API オブジェクトのデバッグ検査で見つかった場合は、そのメソッドの使用を避ける必要もあります。

コードをレビューして非推奨のメソッドを確認する

クライアント API は、開発および改良が続けられています。コードベースをレビューし、非推奨のメソッドを使用していないか確認して、ドキュメントで推奨されたメソッドに置き換えることが重要です。ソリューションチェッカーを使用すると、こうしたメソッドを問題として検出することができます。

フォームやリボンコマンドで jQuery を使用することは避ける

jQuery および他のダイレクト HTML DOM 操作ライブラリは、フォームスクリプトやコマンドバーコマンドではサポートされていません。スクリプトは、クライアント API オブジェクトモデルのメソッドのみを使用するよう制限を設ける必要があります。詳細については、「クライアント API オブジェクトモデルについて」を参照してください。

ノンブロッキングコードを記述する

クエリやプロセスを多用するアクティビティを実行する場合は、非同期パターンを使用して、ノンブロッキングなユーザーエクスペリエンスを確保する必要があります。

確認ダイアログなどの UI をブロックしたり、進捗状況インジケーターをブロックしたりするメソッドを使用しないでください。アプリやフォームで確認しやすいアラート領域に非侵入型で通知を送るようなメカニズムを使用して、ユーザーと対話する方法を検討してください。

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

導入するスクリプトは必ずテストを行い、すべてのブラウザーおよびモデル駆動型アプリのユーザーにより使用されるデバイスフォームファクターで動作することを確認してください。詳細については、「サポートされる Web ブラウザーとモバイルデバイス」を参照してください。

続行

クライアント スクリプトの記述に関するベスト プラクティス

ソリューション チェッカーを使用する

ビジネス ルールとクライアント スクリプトの比較

関連データの参照