ユーザー カスタム アクションおよび ECB メニュー項目の SharePoint Framework 拡張機能への移行
SharePoint Framework (SPFx) は、SharePoint のカスタマイズを拡張および構築するための推奨される開発モデルです。 SharePoint Feature Framework を使用してユーザー カスタム アクションとカスタムの [コントロール ブロックの編集 (ECB)] メニュー項目を使用して SharePoint をカスタマイズした場合、SPFx に移行する利点は何か疑問に思うかもしれません。
まず、SharePoint Framework (SPFx) 拡張機能を開発するときに使用できるオプションを紹介します。
- アプリケーション カスタマイザー: "モダン" ページの事前定義されたプレースホルダーにカスタム HTML 要素とクライアント側コードを追加することによって、SharePoint のネイティブ "モダン"UI を拡張します。 アプリケーション カスタマイザーの詳細については、「SharePoint Framework の最初の拡張機能をビルドする (Hello World パート 1)」を参照してください。
- コマンド セット: リストまたはライブラリのリスト ビューのコマンド バーにカスタム ECB メニュー項目またはカスタム ボタンを追加します。 これらのコマンドには、任意のクライアント側アクションを関連付けることができます。 コマンド セットの詳細については、「最初の ListView コマンド セット拡張機能をビルドする」を参照してください。
- フィールド カスタマイザー: カスタム HTML 要素とクライアント側コードを使用して、リスト ビュー内のフィールドの表示をカスタマイズします。 フィールド カスタマイザーの詳細については、「最初のフィールド カスタマイザー拡張機能をビルドする」を参照してください。
カスタマイズのターゲットに応じて、上記のオプションのいずれかを活用できます。 たとえば、アプリケーション カスタマイザーはユーザー カスタム アクションの代わりとして最適です。 コマンド セット は、ECB メニュー項目の適切な置き換えです。 最後に、 フィールド カスタマイザー は JSLink/Client-Side-Rendering (CSR) のカスタマイズを置き換えることを目的としています。
既存の SharePoint フィーチャー フレームワークのカスタマイズを SharePoint Framework に移行する利点
SharePoint Framework は SharePoint の新しい "モダン" エクスペリエンスを考慮して作成されました。これは、"モダン" チーム サイトと "モダン" コミュニケーション サイトで利用可能で、任意のデバイスと任意のプラットフォームをターゲットとしています。
スクリプトなしの "モダン" サイトをカスタマイズする唯一のサポートされている方法
従来の SharePoint Feature Framework のカスタマイズを SharePoint Framework に移行する主な利点の 1 つは、UI をカスタマイズするための最新のサイトでサポートされている唯一の手法です。
実際、"モダン" サイトではスクリプトなしフラグが有効になっています。これにより、ページに埋め込まれたスクリプトや、外部 JavaScript または埋め込み JavaScript を参照するユーザー カスタム アクションの実行が回避されます。
従来のユーザー カスタム アクションは、単に "モダン" UI では機能しません。 フィーチャー フレームワークを使用して構築された ECB のカスタマイズは制限されています。 外部 JavaScript ファイルを参照しない ECB 項目、または埋め込み JavaScript 呼び出しを使用しない ECB 項目のみを定義できます。 "モダン" UI を実際に拡張する場合は、SharePoint Frameworkにアップグレードする必要があります。
SharePoint と Microsoft 365 の情報へのアクセスが容易
もう 1 つの基本的な点は、ユーザー カスタム アクションと ECB カスタマイズのレガシ モデルでは、SharePoint のコンテンツとデータを簡単に使用できなかったということです。 これを行う唯一の方法は、JSON (SharePoint の JavaScript のクライアント側オブジェクト モデル) または低レベルの REST API を使用することでした。 さらに、ADAL.JS (JavaScript 用 Azure Active Directory 認証ライブラリ) とカスタム JavaScript コードを自律的に利用しない限り、Microsoft 365 のサービスの完全なセットを使用することはほとんど不可能でした。
これで、SharePoint FrameworkとSharePoint Framework拡張機能を使用すると、SharePoint REST API と Microsoft Graph の両方を簡単かつ簡単に使用できます。 Microsoft 365 によって提供されるサービスの完全なエコシステムを使用して操作できる、より強力なソリューションを作成できるようになりました。
SharePoint Framework ソリューションと SharePoint フィーチャー フレームワーク カスタマイズの類似点
SharePoint Feature Framework ユーザー カスタム アクションと ECB アイテムと SharePoint Feature Framework のカスタマイズの両方で、いくつかの類似点が共有されます。
プロビジョニング モデル
SharePoint Framework拡張機能とユーザー カスタム アクションまたは ECB メニュー項目ソリューションの両方が、SharePoint Feature Framework 構文で記述された XML マニフェスト ファイルを利用します。デプロイは同じ手法に基づいています。
ページのパーツとして実行される
ユーザー カスタム アクションと SharePoint フィーチャー フレームワークの ECB と同様に、SharePoint Framework 拡張機能はページのパーツです。 このため、これらのソリューションはページの DOM にアクセスでき、同じページ上の他のコンポーネントと通信できます。 また、開発者はより簡単にソリューションの応答性を向上させて、SharePoint モバイル アプリを含む SharePoint ページを表示できる種々のフォーム ファクターに適合させることができます。
SharePoint Framework 拡張機能はページのパーツとして実行されるので、カスタマイズがアクセスできるリソースにはどれでも、対象ページ上の他の要素もアクセスできます。 これは、Bearer アクセス トークンを使用する OAuth 暗黙的フローに依存したり、機密情報を格納するために cookies またはブラウザーを使用したりするソリューションをビルドするときに銘記しておくべき重要な点です。 SharePoint Framework 拡張機能はページのパーツとして実行されるので、対象ページ上の他の要素もすべてのリソースにアクセスできます。
任意のライブラリを使用して拡張機能をビルドする
ユーザー カスタム アクションを使用してページのカスタマイズを作成するときに、jQuery や Knockout などのライブラリを使用して動的なカスタマイズを実装し、ユーザーの操作により適切に対応している可能性があります。 SharePoint Framework 拡張機能をビルドするときは、従来と同じ方法を使用して、任意のクライアント側のライブラリによってソリューションを強化できます。
SharePoint Frameworkが提供するその他の利点は、スクリプトの分離です。 Web パーツはページの一部として実行されますが、そのスクリプトはモジュールとしてパッケージ化されているため、同じページ上の異なる拡張機能が相互に衝突することなく異なるバージョンの jQuery を使用できます。 この強力な機能により、技術的な移行を必要としたり、機能的に妥協したりすることなく、ビジネス上の価値の配信に重点を置くことが可能になります。
現在のユーザーとして実行される
ユーザー カスタム アクションと ECB メニュー項目を使用してビルドされるカスタマイズでは、SharePoint と通信が必要になるときには API を呼び出すだけで済みました。 クライアント側ソリューションは現在のユーザーのコンテキストでブラウザーにおいて実行され、要求と一緒に認証 Cookie を自動的に送信することによって、ソリューションは SharePoint に直接接続できました。 SharePoint アドインを使用する場合と同様に、追加の認証は SharePoint と通信するために必要ありませんでした。
同じメカニズムが SharePoint Framework でビルドされたカスタマイズに当てはまります。現在認証されているユーザーのコンテキストで実行され、SharePoint と通信するための追加の認証手順は不要です。 セキュリティ コンテキストは、現在接続されているユーザーのコンテキストです。つまり、セキュリティの観点から、任意のターゲット サイト コレクションにSharePoint Framework拡張機能をインストールするときは注意する必要があります。
クライアント側のコードのみを使用する
SharePoint Framework 拡張機能と、ユーザー カスタム アクションまたは ECB メニュー項目のソリューションは両方ともブラウザーで実行され、クライアント側の JavaScript コードのみを含めることができます。 クライアント側ソリューションには、いくつかの制限があります。たとえば、SharePoint のアクセス許可を昇格することができなかったり、クロス オリジン通信 (CORS) または OAuth 暗黙的フローによる認証をサポートしていない外部 API にアクセスできなかったりします。 このような場合、クライアント側ソリューションはリモート サーバー側 API を利用して必要な操作を行い、結果をクライアントに返すことができます。
Microsoft 365 に基づく、自己一貫性のあるホスティング モデル
SharePoint Framework拡張機能とユーザー カスタム アクションまたは ECB メニュー項目ソリューションの両方を SharePoint Online でホストでき、最終的には Microsoft 365 CDN サービスでホストできるため、外部サービスやホスティング環境が不要になります。
CDN でSharePoint Framework ソリューションをホストする場合、多くの利点が得られますが、必須ではありません。また、SharePoint ドキュメント ライブラリでコードをホストすることもできます。 アプリ カタログにデプロイされたSharePoint Framework パッケージ (*.sppkg ファイル) は、ソリューションのコードを見つけることができる URL SharePoint Framework指定します。 拡張機能を含むページを参照するユーザーが、指定の場所からスクリプトをダウンロードできる場合は、指定する URL に制限はありません。
Microsoft 365 には、特定の SharePoint ドキュメント ライブラリから CDN にファイルを発行できるパブリック CDN 機能が用意されています。 Microsoft 365 パブリック CDN では、CDN を使用する利点と、SharePoint ドキュメント ライブラリでコード ファイルをホストするシンプルさのバランスが取られます。 組織がコード ファイルを公開することを気にしない場合は、Microsoft 365 パブリック CDN を使用することを検討する価値があります。
SharePoint Framework ソリューションと SharePoint フィーチャー フレームワーク カスタマイズの相違点
ただし、2 つの開発モデルには大きな相違点があり、ソリューションのアーキテクチャを設計する際には考慮する必要があります。
スクリプトなしのサイトで実行する
拡張機能を含むSharePoint Frameworkソリューションは、事前の承認を得てアプリ カタログを通じてデプロイされるため、スクリプトなしの制限の対象ではなく、すべての "モダン" サイトで作業します。
事前定義された一連の拡張性ポイント
ユーザー カスタム アクションは、ページの任意の部分の DOM を更新または変更できる JavaScript コードを埋め込むことができますが、SharePoint Framework拡張機能は、サポートされている "モダン" ページの領域のみをカスタマイズできます。
理論的には、ユーザー カスタム アクションの場合と同様に、DOM を使用してページの構造を完全に変更するアプリケーション カスタマイザーを作成できます。 SharePoint Framework では、SharePoint をカスタマイズするためにより構造化され、信頼性の高い方法が推奨されています。 特定の DOM 要素を使用して SharePoint をカスタマイズするのではなく、SharePoint Framework には開発者がカスタマイズに使用するフックとプレースホルダーが用意されており、それだけを使用すべきです。
より堅固なソリューションをビルドし、保守を簡単にするために TypeScript を使用する
ユーザー カスタム アクションまたは ECB メニュー項目を使用してカスタマイズをビルドする場合、開発者は JavaScript を使用することがよくあります。 そのようなソリューションには自動化されたテストが含まれておらず、コードのリファクタリングでエラーが生じやすい場合が少なくありませんでした。
SharePoint Framework を使用すると、開発者はソリューションのビルド時に TypeScript 型のシステムの利点を生かすことができます。 型システムのおかげで、実行時ではなく開発中に多くのエラーが発生します。 また、TypeScript によってコードに対する変更がセーフガードされるので、コードのリファクタリングもより簡単に実行できます。 すべての JavaScript は有効な TypeScript なので、エントリ障壁が低く、プレーンな JavaScript を時間の経過とともに徐々に TypeScript に移行し、ソリューションの保守能力を向上させていくことができます。
既定では SharePoint JavaScript オブジェクト モデルにアクセスできない
SharePoint クラシック ユーザー エクスペリエンス向けのクライアント側カスタマイズをビルドする場合、多くの開発者は JavaScript オブジェクト モデル (JSOM) を使用して SharePoint と通信しました。 JSOM により、クライアント側オブジェクト モデル (CSOM) と同じような方法で、SharePoint API に対して IntelliSense と簡単なアクセスが提供されてきました。 従来の SharePoint ページでは、JSON のコア要素は既定でページ上に存在し、開発者は、SharePoint Search との通信などのために追加要素を読み込むことができました。
SharePoint モダン ユーザー エクスペリエンスには既定で SharePoint JSOM は含まれていません。 開発者は自分でそれを読み込むことはできますが、REST API、または内部で SharePoint Rest API を使用する SharePoint パターンとプラクティスの JavaScript コア ライブラリ (PnP JS ライブラリ) を代わりに使用することをお勧めします。 REST の使用は、jQuery、Angular、React などの異なるクライアント側ライブラリ間でより汎用的で交換可能です。
Microsoft は JSOM に関して積極的な投資は行っていません。 API を使用する場合は、代わりに PnP JS ライブラリを使用できます。このライブラリでは、Fluent API と TypeScript の入力が提供されます。
既存のカスタマイズを SharePoint Framework 拡張機能に移行する
既存のカスタマイズを SharePoint Framework 拡張機能に移行すると、エンドユーザーと開発者の両方にとって多数の利点があります。 既存のカスタマイズをSharePoint Frameworkに移行することを検討する場合は、既存の JavaScript スクリプトをできるだけ多く再利用するか、TypeScript を使用してカスタマイズを完全に書き直すかのいずれかを選択できます。
既存のスクリプトを再利用する
既存のカスタマイズを SharePoint Framework 拡張機能に移行する場合、既存のスクリプトを再利用することもできます。 SharePoint Framework では TypeScript の使用が推奨されていますが、プレーンな JavaScript を使用して徐々に TypeScript に変換していくこともできます。 ソリューションを限られた期間だけサポートする必要がある場合や、予算が限られている場合には、この方法で十分な場合もあります。
SharePoint Framework ソリューションで既存のスクリプトを再利用することはいつでも可能とは限りません。 たとえば、さまざまな JavaScript ライブラリがある場合、既存のスクリプトをSharePoint Framework ソリューションで再利用できるか、書き換える必要があるかを簡単に判断する方法はありません。 見極める唯一の方法は、さまざまな部分を SharePoint Framework ソリューションに移行し、正常に動作するかどうか確認することです。
カスタマイズを再作成する
ソリューションを長期間サポートする必要がある場合、またはSharePoint Frameworkをより適切に使用したい場合、または既存のスクリプトをSharePoint Frameworkで再利用できないことが判明した場合は、カスタマイズを完全に書き直す必要がある場合があります。 既存のスクリプトを再利用するよりもコストがかかりますが、より長い期間にわたってより優れた結果を提供します。これは、より優れた実行と保守が容易なソリューションです。
既存のカスタマイズをSharePoint Framework ソリューションに書き換える場合は、必要な機能を念頭に置いて開始する必要があります。 ユーザー エクスペリエンスを実装するため、Office UI Fabric の使用を検討してください。それにより、ソリューションが SharePoint の不可欠な部分のようになります。