JSLink カスタマイズを SharePoint Framework フィールド カスタマイザーに移行する
SharePoint Framework (SPFx) は、SharePoint のカスタマイズを拡張および構築するための推奨モデルです。 JSLink で SharePoint フィールドとリスト ビューをカスタマイズした場合、これらのカスタマイズを SPFx に移行する利点は何か疑問に思うかもしれません。
最初に、SharePoint Framework 拡張機能を開発するときに使用できるオプションを紹介します。
- アプリケーション カスタマイザー: "モダン" ページの事前定義されたプレースホルダーにカスタム HTML 要素とクライアント側コードを追加することによって、SharePoint のネイティブ "モダン"UI を拡張します。 アプリケーション カスタマイザーの詳細については、「SharePoint Framework の最初の拡張機能をビルドする (Hello World パート 1)」を参照してください。
- コマンド セット: カスタムの編集コントロール ブロック (ECB) のメニュー項目またはカスタム ボタンを、リストまたはライブラリのリスト ビューのコマンド バーに追加します。 これらのコマンドには、任意のクライアント側アクションを関連付けることができます。 コマンド セットの詳細については、「最初の ListView コマンド セット拡張機能をビルドする」を参照してください。
- フィールド カスタマイザー: カスタム HTML 要素とクライアント側コードを使用して、リスト ビュー内のフィールドの表示をカスタマイズします。 フィールド カスタマイザーの詳細については、「最初のフィールド カスタマイザー拡張機能をビルドする」を参照してください。
カスタマイズのターゲットに応じて、上記のオプションのいずれかを活用できます。 たとえば、フィールド カスタマイザーは、フィールドの JSLink カスタマイズの代わりとして適しています。
ヒント
フィールド カスタマイザーは JSLink からの自然な移行パスですが、リスト ビューをカスタマイズするには、リストと列の書式設定を使用して評価する必要もあります。 どちらのテクノロジにも個別の長所と短所があり、シナリオによっては、実装と保守が他のテクノロジよりも簡単になる場合があります。
詳細については、「列の書式設定を使用して SharePoint をカスタマイズする」を参照してください。
既存の JSLink カスタマイズを SharePoint Framework に移行する利点
SharePoint Frameworkは、SharePoint の "モダン" エクスペリエンスを拡張するために構築されました。 "モダン" エクスペリエンスは、"モダン" チーム サイトと "モダン" コミュニケーション サイトで利用でき、どのデバイスやプラットフォームも対象としています。
"モダン" リストと "モダン" ライブラリをカスタマイズするためにサポートされている唯一の方法
従来の JSLink カスタマイズをSharePoint Frameworkに移行する主な利点の 1 つは、サポートされている唯一のオプションであるということです。 実際、"モダン" リストとライブラリは、レンダリング インフラストラクチャと "モダン" サイトでスクリプト なし フラグが有効になっているため、従来の JSLink カスタマイズに依存できません。 実際に "モダン" UI を拡張する場合は、JSLink ソリューションを SharePoint Framework フィールド カスタマイザーに移行する必要があります。
SharePoint と Microsoft 365 の情報へのアクセスが容易
考慮すべきもう 1 つの基本的なトピックは、従来の JSLink のカスタマイズでは、SharePoint のコンテンツとデータを簡単に使用できなかったということです。 これを行う唯一の方法は、JavaScript クライアント側オブジェクト モデル (JSOM) または低レベルの 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 フィーチャー フレームワーク カスタマイズの類似点
JSLink のカスタマイズと SharePoint Feature Framework のカスタマイズの両方で、いくつかの類似点が共有されます。
プロビジョニング モデル
SharePoint Framework拡張機能とユーザー カスタム アクションまたは ECB メニュー項目ソリューションの両方で、SharePoint Feature Framework 構文で記述された XML マニフェスト ファイルが使用されます。 そのため、同じ手法に基づいて展開されます。 ただし、新しいフィールド カスタマイザーにより、リストまたはライブラリの単一ビューのレンダリングではなく、フィールドのレンダリングをカスタマイズできます。 ユーザー設定フィールドは、必要な数のリストとライブラリで使用できます。
ページのパーツとして実行される
SharePoint Feature Framework のユーザー カスタム アクションや ECB と同様に、SharePoint Framework拡張機能はページの一部です。 このため、これらのソリューションはページの DOM にアクセスでき、同じページ上の他のコンポーネントと通信できます。 また、開発者はより簡単にソリューションの応答性を向上させて、SharePoint モバイル アプリを含む SharePoint ページを表示できる種々のフォーム ファクターに適合させることができます。
SharePoint Framework拡張機能はページの一部として実行されるため、カスタマイズがアクセスできるリソースに関係なく、ページ上の他の要素もアクセスできます。 これは、Bearer アクセス トークンを使用する OAuth 暗黙的フローに依存したり、機密情報を格納するために cookies またはブラウザーを使用したりするソリューションをビルドするときに銘記しておくべき重要な点です。 SharePoint Framework拡張機能はページの一部として実行されるため、そのページ上の他の要素もこれらすべてのリソースにアクセスできます。
任意のライブラリを使用して拡張機能をビルドする
ユーザー カスタム アクションを使用してページのカスタマイズをビルドする場合、jQuery や Knockout などのライブラリを使用してカスタマイズを動的にしたり、ユーザー操作への応答を向上させたりできました。 SharePoint Framework拡張機能を構築する場合は、クライアント側のライブラリを使用して、以前と同じ方法でソリューションをエンリッチできます。
SharePoint Framework によってもたらされるその他の利点として、スクリプトの分離があります。 Web パーツはページのパーツとして実行されますが、そのスクリプトはモジュールとしてパッケージ化されるため、たとえば、同じページ上の異なる拡張機能は別のバージョンの jQuery を相互に衝突することなく利用できます。 この強力な機能により、技術的な移行を必要としたり、機能的に妥協したりすることなく、ビジネス上の価値の配信に重きを置くことが可能になります。
現在のユーザーとして実行される
JSLink を使用してビルドされるカスタマイズの場合、SharePoint と通信が必要になるときには API を呼び出すだけで済みました。 クライアント側ソリューションは現在のユーザーのコンテキストでブラウザーにおいて実行され、要求と一緒に認証 Cookie を自動的に送信することによって、ソリューションは SharePoint に直接接続できました。 SharePoint アドインを使用する場合と同様に、追加の認証は SharePoint と通信するために必要ありませんでした。
同じメカニズムが SharePoint Framework でビルドされたカスタマイズに当てはまります。現在認証されているユーザーのコンテキストで実行され、SharePoint と通信するための追加の認証手順は不要です。 セキュリティ コンテキストは、現在接続されているユーザーのコンテキストです。つまり、セキュリティの観点から、任意のターゲット サイト コレクションにSharePoint Framework拡張機能をインストールするときは注意する必要があります。
クライアント側のコードのみを使用する
SharePoint Framework拡張機能と JSLink のカスタマイズはどちらもブラウザーで実行され、クライアント側の JavaScript コードのみを含めることができます。 クライアント側ソリューションには、いくつかの制限があります。たとえば、SharePoint のアクセス許可を昇格することができなかったり、クロス オリジン通信 (CORS) または OAuth 暗黙的フローによる認証をサポートしていない外部 API にアクセスできなかったりします。 このような場合、クライアント側ソリューションはリモート サーバー側 API を利用して必要な操作を行い、結果をクライアントに返すことができます。
Microsoft 365 に基づく、自己一貫性のあるホスティング モデル
JSLink カスタマイズ用の SharePoint Framework 拡張機能と JavaScript ファイルの両方を 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 ソリューションと JSLink カスタマイズの相違点
ただし、2 つの開発モデルには大きな相違点があり、ソリューションのアーキテクチャを設計する際には考慮する必要があります。
スクリプトなしのサイトと、"モダン" リストと "モダン" ライブラリで実行する
拡張機能を含むSharePoint Frameworkソリューションは、事前の承認を得てアプリ カタログを通じてデプロイされるため、スクリプトなしの制限の対象ではなく、すべての "モダン" サイトで作業します。 既に説明したように、SharePoint Frameworkのフィールド カスタマイザーは"モダン" リストとライブラリで動作しますが、従来の JSLink は機能しません。
フィールド カスタマイザーはビューのみのシナリオをサポートする
JSLink カスタマイズは、リストまたはライブラリ内のフィールドのビューだけでなく、単一項目を表示する際のフィールドのディスプレイ ビューおよび編集ビューをカスタマイズするために使用できます。
この執筆時点では、SharePoint Frameworkのフィールド カスタマイザーは、リスト ビューレンダリングモードでのみフィールドのレンダリングをカスタマイズできますが、1 つのアイテムの表示および編集ビューではカスタマイズを利用できません。
より堅固なソリューションをビルドし、保守を簡単にするために TypeScript を使用する
JSLink を使用してカスタマイズをビルドするとき、多くの場合、開発者はプレーンな JavaScript を使用してきました。 そのようなソリューションには自動化されたテストが含まれておらず、コードのリファクタリングでエラーが生じやすい場合が少なくありませんでした。
SharePoint Framework を使用すると、開発者はソリューションのビルド時に TypeScript 型のシステムの利点を生かすことができます。 この型のシステムにより、実行時ではなく、開発中にエラーをキャッチできます。 また、TypeScript によってコードに対する変更がセーフガードされるので、コードのリファクタリングもより簡単に実行できます。 すべての JavaScript は有効な TypeScript なので、エントリ障壁が低く、プレーンな JavaScript を時間の経過とともに徐々に TypeScript に移行し、ソリューションの保守能力を向上させていくことができます。
既定では SharePoint JavaScript オブジェクト モデルにアクセスできない
従来の SharePoint ユーザー エクスペリエンスのクライアント側のカスタマイズを構築する場合、多くの開発者は JSOM を使用して SharePoint と通信しました。 JSOM は、Client-Side オブジェクト モデル (CSOM) と同様の方法で、IntelliSense と SharePoint API への簡単なアクセスを提供しました。 従来の SharePoint ページでは、JSOM のコア部分が既定でページに存在し、開発者は SharePoint Search と通信するために追加の部分を読み込むことができます。
既定では、SharePoint モダン ユーザー エクスペリエンスには SharePoint JSOM は含まれていません。 開発者は自分で読み込むことができますが、代わりに REST API、または SharePoint REST API を内部的に使用する SharePoint パターンとプラクティス JavaScript Core ライブラリ (PnPJS) を使用することをお勧めします。 REST の使用は、jQuery、Angular、React などの異なるクライアント側ライブラリ間でより汎用的で交換可能です。
Microsoft は JSOM に積極的に投資していません。 API を使用する場合は、Fluent API と TypeScript 型宣言を提供する PnP JS ライブラリを使用できます。
既存のカスタマイズを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 の不可欠な部分のようになります。