SharePoint Framework を選択する理由

SharePoint は、2001 年にオンプレミス製品として最初に発売されました。時間が経つにつれて、大規模な開発者コミュニティが広がり、さまざまな方法で形成されるようになりました。開発者コミュニティは、Web パーツ、SharePoint 機能の XML など SharePoint の製品開発チームが使用する同じパターンとプラクティスに従っています。多くの機能は、C# を使用してサーバー側のカスタマイズとして記述され、DLL にコンパイルされ、オンプレミスのサーバーファームにデプロイされました。

そのアーキテクチャは 1 つのエンタープライズのみの環境ではうまく機能しましたが、同じサーバー上で複数のテナントが並行して実行するクラウドにまで拡大しませんでした。その結果、クライアント側の JavaScript インジェクションと SharePoint アドインという 2 つの代替モデルを導入しました。これらのソリューションにはどちらも長所と短所があります。

JavaScript インジェクション

SharePoint Online で最も人気のある Web パーツの 1 つは、スクリプトエディターです。 JavaScript をスクリプトエディター Web パーツに追加し、ページにレンダリングするときにその JavaScript を実行することができます。これは簡単に効果的です & 。ページと同じブラウザーのコンテキストで実行し、同じ DOM にあるので、ページ上の他のコントロールと相互作用することができます。比較的高性能で、容易に使用できます。

このアプローチにはいくつか欠点があります:

ソリューションをパッケージ化することができるので、エンドユーザーはページ上にコントロールをドロップできるのですが、構成オプションを簡単に提供することはできません。
エンドユーザーはページを編集し、スクリプトを修正できるので、Web パーツを壊してしまう可能性があります。
スクリプトエディター Web パーツは、「スクリプトを実行しても安全」だとマークされていません。ほとんどのセルフサービスサイトコレクション (個人用サイト、チームサイト、グループサイト) には、有効な「NoScript」と呼ばれる機能があります。技術的には、ページの追加とカスタマイズ (ACP) アクセス許可の SharePoint 内での削除です。つまり、スクリプトエディター Web パーツがこれらのサイトで実行をブロックされるということです。

SharePoint アドインモデル

NoScript のサイトで実行されているソリューションの 1 つのオプションは、SharePoint Server 2013 で導入されたアドイン/アプリケーションパートモデルです。この実装は、実際の経験が存在し、実行する iFrame を作成します。利点は、システムの外部にあり、現在の DOM と接続へのアクセス権を持たないため、IT ワーカーがより容易に信頼し、展開することができます。エンドユーザーは、NoScript のサイト上のアドインをインストールすることができます。

このアプローチにもいくつか欠点があります

それらは iFrame で実行されます。 iFrame は、別のページに新しい要求を必要とするため、スクリプトエディター Web パーツよりも遅くなります。ページは、完全な認証と承認を経て、SharePoint のデータを取得する独自の呼び出しを行い、さまざまな JavaScript ライブラリの読み込みなどを行う必要があります。例として、通常、スクリプトエディター Web パーツは読み込みとレンダリングに 100 ミリ秒かかりますが、アプリパーツでは 2 秒以上かかる場合があります。
iFrame の限界が応答性の高いデザインの作成、および CSS とテーマの継承を困難にしています。 iFrame にはより強力なセキュリティがあり、開発者自身 (自分のページは、ページ上の他者のコントロールでアクセスできません) とエンドユーザー (コントロールには、Microsoft 365 の接続へのアクセス権がありません) に役立ちます。