既存のスクリプト エディター Web パーツのカスタマイズを SharePoint Framework に移行するMigrate existing Script Editor Web Part customizations to the SharePoint Framework

SharePoint Framework は、SharePoint カスタマイズをビルドするためのモデルです。SharePoint Framework is a model for building SharePoint customizations. スクリプト エディター Web パーツを使用してクライアント側の SharePoint ソリューションをビルドしてきた場合、SharePoint Framework に移行する利点とは何かと考えるかもしれません。If you have been building client-side SharePoint solutions by using the Script Editor Web Part, you might be wondering what the possible advantages are of migrating them to the SharePoint Framework.

この記事では、既存のクライアント側カスタマイズを SharePoint Framework へ移行することの利点を強調し、移行を計画する際に考慮する必要のある事柄をいくつか示します。This article highlights the benefits of migrating existing client-side customizations to the SharePoint Framework and points out a number of considerations that you should take into account when planning the migration.

注意

この記事の情報は、コンテンツ エディター Web パーツとスクリプト エディター Web パーツのどちらを使用してビルドされたカスタマイズにも適用されます。The information in this article applies to customizations built using both the Content- and the Script Editor Web Part. スクリプト エディター Web パーツに言及している場合は常に、 コンテンツ エディター Web パーツおよびスクリプト エディター Web パーツ と置き換えて読んでください。Wherever there is a reference to the Script Editor Web Part, you should read Content Editor Web Part and Script Editor Web Part.

既存のクライアント側カスタマイズを SharePoint Framework に移行する利点Benefits of migrating existing client-side customizations to the SharePoint Framework

SharePoint Framework は、クライアント側の開発に重点を置いた SharePoint 開発モデルとして一からビルドされてきました。SharePoint Framework has been built from the ground up as a SharePoint development model focusing on client-side development. 主に、モダン チーム サイト向けの拡張性機能を提供しますが、SharePoint Framework に基づいてビルドされたカスタマイズは SharePoint クラシック エクスペリエンスでも動作します。While it primarily offers extensibility capabilities for modern team sites, customizations built on the SharePoint Framework also work with the classic SharePoint experience. SharePoint Framework を使用してカスタマイズをビルドすることには、現在利用できる他の SharePoint 開発モデルを使用する場合に比べて、より多くの利点があります。Building your customizations by using the SharePoint Framework offers you a number of benefits over using any other SharePoint development model available to date.

一度ビルドして、すべてのデバイスで再利用するBuild once, reuse across all devices

SharePoint モダン ユーザー エクスペリエンスは、あらゆるデイバスの SharePoint に格納されている情報に対するアクセスをネイティブでサポートするよう設計されています。The modern SharePoint user experience has been designed to natively support access to information stored in SharePoint on any device. さらに、モダン エクスペリエンスは SharePoint モバイル アプリもサポートします。Additionally, the modern experience supports the SharePoint mobile app. SharePoint Framework を使用してビルドするソリューションは SharePoint モダン エクスペリエンスとシームレスに統合し、SharePoint モバイル アプリ内と同様に、別のデバイスでも使用できます。Solutions built using the SharePoint Framework seamlessly integrate with the modern SharePoint experience and can be used across the different devices as well as inside the SharePoint mobile app. SharePoint Framework ソリューションは SharePoint クラシック エクスペリエンスでも動作するため、モダン エクスペリエンスにまだ移行していない組織でも使用できます。Because SharePoint Framework solutions also work with the classic SharePoint experience, they can be used by organizations that haven't migrated to the modern experience yet.

より堅牢で将来も使用可能More robust and future-proof

開発者は、これまでは、ユーザー インターフェイスに特定の DOM 要素を追加して SharePoint をカスタマイズしてきました。この方法を使って、標準のユーザー エクスペリエンスを変更したり、エンド ユーザーに追加機能を提供したりすることがありました。しかし、こうしたソリューションではエラーが発生しやすい状況でした。SharePoint ページの DOM は拡張可能なサーフェイスではないため、変更の際に、この DOM に依存するソリューションは壊れる可能性がありました。In the past, developers were customizing SharePoint by attaching to specific DOM elements in the user interface. Using this approach, they could change the standard user experience or provide additional functionality to end users. Such solutions were however error-prone. Because the SharePoint page DOM was never meant as an extensibility surface, whenever it changed, solutions relying on it would break.

SharePoint Framework は、標準化された API と拡張性ポイントを開発者に提供します。開発者はそれらを利用して、クライアント側ソリューションをビルドしたり、エンド ユーザーに追加機能を提供したりできます。SharePoint Framework offers developers standardized API and extensibility points to build client-side solutions and provide end-users with additional capabilities. 開発者は SharePoint Framework を使用して、サポートを受けながら将来も利用できる方法でソリューションをビルドでき、将来の SharePoint ユーザー インターフェイスの変更がソリューションに与えるかもしれない影響を心配する必要がありません。Developers can use the SharePoint Framework to build solutions in a supported and future-proof way, and don't need to be concerned with how future changes to the SharePoint user interface could affect your solution.

SharePoint と Office 365 の情報へのアクセスが容易Easier access to information in SharePoint and Office 365

Microsoft は SharePoint と Office 365 の機能を継続的に強化しています。これら両方のプラットフォームをよく利用する組織にとっては、Office 365 に格納されている情報と分析内容を上手に活用して高機能のソリューションを開発者がビルドできることの重要性が増しています。SharePoint Framework が掲げる 1 つの目標は、開発者が各種の SharePoint API と Office 365 API に簡単に接続でできるようにすることです。Microsoft is continuously extending capabilities of SharePoint and Office 365. As organizations make more use of both platforms, it's becoming increasingly important for developers to be able to tap into the information and insights stored in Office 365 to build rich solutions. One of the goals of the SharePoint Framework is to make it easy for developers to connect to various SharePoint and Office 365 APIs.

ユーザーのニーズに応じてソリューションを構成できるEnable users to configure solutions to their needs

スクリプトを埋め込んでビルドするクライアント側ソリューションの場合、エンドユーザーはニーズに応じてソリューションを簡単に構成することはできませんでした。そうしたソリューションを構成する唯一の方法は、特定の目的にためにコードを変更するか、ユーザー インターフェイスをカスタマイズすることでした。Client-side solutions built through script embedding often didn't offer end-users an easy way to configure them to their needs. The only way to configure such solution, was by altering its code or through a custom user interface built specifically for that purpose.

SharePoint Framework クライアント側 Web パーツには、従来のクラシック Web パーツで作業してきたユーザーにとって親しみ深いプロパティ ウィンドウを使用して Web パーツを構成する標準的な方法が備わっています。クライアント側 Web パーツをビルドする開発者は、Web パーツに再有効化プロパティ ウィンドウ (その場合、Web パーツ プロパティへのそれぞれの変更が Web パーツ本体へ直接反映される) を含める (既定) か、または非再有効化プロパティ ウィンドウ (その場合、Web パーツ プロパティへの変更は明示的に適用する必要がある) にするかを選択できます。SharePoint Framework client-side web parts offer a standard way for configuring web parts using a property pane - familiar to users who worked with classic web parts in the past. Developers building client-side web parts can choose whether their web part should have a reactive property pane (default), where each change to a web part property is directly reflected in the web part body, or a non-reactive property pane, where changes to web part properties must be explicitly applied.

スクリプトなしのサイトで動作するWork on no-script sites

組織におけるカスタマイズの制御を支援するため、Microsoft は SharePoint Online でスクリプトなしの機能をリリースしました。To help organizations govern their customizations, Microsoft released the no-script capability in SharePoint Online. テナントまたは特定のサイト コレクションでスクリプトなしのフラグが有効になっていると、スクリプト インジェクションとスクリプト埋め込みに依存するカスタマイズは行えません。When the tenant or a particular site collection has the no-script flag enabled, customizations relying on script injection and embedding are disabled.

SharePoint Framework のクライアント側 Web パーツは事前承認を受けたアプリ カタログ経由で配置されるため、スクリプトなしのサイトで実行できます。Because SharePoint Framework client-side web parts are deployed through the app catalog with a prior approval, they are allowed to run in no-script sites. 既定では、モダン チーム サイトではスクリプトなし設定が有効な状態で、サイトにスクリプトを埋め込むことはできません。By default, modern team sites have the no-script setting enabled and it's not possible to embed scripts in these sites. これにより、モダン チーム サイトでクライアント側カスタマイズをビルドするための唯一のサポートされている方法は、SharePoint Framework の使用だけになります。This makes using the SharePoint Framework the only supported way to build client-side customizations in modern team sites.

SharePoint Framework ソリューションとスクリプト エディター Web パーツ カスタマイズの類似点Similarities between SharePoint Framework solutions and Script Editor Web Part customizations

SharePoint Framework ソリューションは、新たなツールチェーンを使用して新しい開発モデルでビルドされていますが、過去にビルドしたスクリプト エディター Web パーツのカスタマイズと類似しています。両者は同じ概念を共有しているため、新しい SharePoint Framework に簡単に移行できます。While built on a new development model using a new toolchain, SharePoint Framework solutions are similar to the Script Editor Web Part customizations you have built in the past. Because they share the same concepts, it makes it easier for you to migrate them to the new SharePoint Framework.

ページのパーツとして実行されるRun as a part of the page

スクリプト エディター Web パーツに埋め込まれたカスタマイズと同様、SharePoint Framework ソリューションもページのパーツです。Similar to customizations embedded in Script Editor Web Parts, SharePoint Framework solutions are part of the page. このため、これらのソリューションはページの DOM にアクセスでき、同じページ上の他のコンポーネントと通信できます。This gives these solutions access to the page's DOM and allows them to communicate with other components on the same page. また、開発者はより簡単にソリューションの応答性を向上させて、SharePoint モバイル アプリを含む SharePoint ページを表示できる種々のフォーム ファクターに適合させることができます。Also, it allows developers to more easily make their solutions responsive to adapt to the different form factors on which a SharePoint page could be displayed, including the SharePoint mobile app.

SharePoint アドインとは異なり、SharePoint Framework クライアント側 Web パーツは iframe で分離されていません。Unlike SharePoint Add-ins, SharePoint Framework client-side web parts are not isolated in an iframe. そのため、特定のクライアント側 Web パーツがアクセスできるリソースに関係なく、ページ上の他の要素にアクセスできます。As a consequence, whatever resources the particular client-side web part has access to, other elements on the page can access as well. これは、Bearer アクセス トークンを使用する OAuth 暗黙的フローに依存したり、機密情報を格納するために cookies またはブラウザーを使用したりするソリューションをビルドするときに銘記しておくべき重要な点です。This is important to keep in mind when building solutions that rely on OAuth implicit flow with bearer access tokens or use cookies or browser storage for storing sensitive information. クライアント側 Web パーツはページのパーツとして実行されるため、対象ページ上の他の要素もすべてのリソースにアクセスできます。Because client-side web parts run as a part of the page, other elements on that page are able to access all these resources as well.

任意のライブラリを使用して Web パーツをビルドするUse any library to build your web part

スクリプト エディター Web パーツを使用してカスタマイズをビルドする場合、jQuery や Knockout などのライブラリを使用してカスタマイズを動的にしたり、ユーザー操作への応答を向上させたりできました。When building customizations using the Script Editor Web Part, you might have used libraries such as jQuery or Knockout to make your customization dynamic and better respond to user interaction. SharePoint Framework クライアント側 Web パーツをビルドする場合、従来と同じ方法を使用して、任意のクライアント側ライブラリによってソリューションを強化できます。When building SharePoint Framework client-side web parts, you can use any client-side library to enrich your solution, the same way you would have done it in the past. SharePoint Framework によってもたらされるその他の利点として、スクリプトの分離があります。An additional benefit that the SharePoint Framework offers you is isolation of your script. Web パーツはページのパーツとして実行されますが、そのスクリプトはモジュールとしてパッケージ化されるため、たとえば、同じページ上の異なる Web パーツは別のバージョンの jQuery を相互に衝突することなく利用できます。Even though the web part is executed as a part of the page, its script is packaged as a module allowing, for example, different web parts on the same page to use a different version of jQuery without colliding with each other. この強力な機能により、技術的な移行を必要としたり、機能的に妥協したりすることなく、ビジネス上の価値の配信に重点を置くことが可能になります。This is a powerful feature that allows you to focus on delivering business value instead of technical migrations and compromising on functionality.

現在のユーザーとして実行されるRun as the current user

スクリプト エディター Web パーツを使用してビルドされるカスタマイズの場合、SharePoint と通信が必要になるときには API を呼び出すだけで済みました。In customizations built using the Script Editor Web Part, whenever you needed to communicate with SharePoint, all you had to do was to call its API. クライアント側ソリューションは現在のユーザーのコンテキストでブラウザーにおいて実行され、要求と一緒に認証 Cookie を自動的に送信することによって、ソリューションは SharePoint に直接接続できました。The client-side solution was running in the browser in the context of the current user, and by automatically sending the authentication cookie along with the request, your solution could directly connect to SharePoint. SharePoint アドインを使用する場合と同様に、追加の認証は SharePoint と通信するために必要ありませんでした。No additional authentication, such as when using SharePoint Add-ins, was necessary to communicate with SharePoint. 同じメカニズムが SharePoint Framework でビルドされたカスタマイズに当てはまります。現在認証されているユーザーのコンテキストで実行され、SharePoint と通信するための追加の認証手順は不要です。The same mechanism applies to customizations built on the SharePoint Framework that also run under the context of the currently authenticated user and also don't require any additional authentication steps to communicate with SharePoint.

クライアント側のコードのみを使用するUse only client-side code

SharePoint Framework ソリューションとスクリプト エディター Web パーツ ソリューションはどちらもブラウザーで実行され、クライアント側の JavaScript コードのみを含めることができます。クライアント側ソリューションには、いくつかの制約があります。たとえば、SharePoint のアクセス許可を昇格することができなかったり、クロス オリジン通信 (CORS) または OAuth 暗黙的フローによる認証をサポートしていない外部 API へアクセスできなかったりします。そのような場合、クライアント側ソリューションはリモート サーバー側 API を使用して、必要な操作を実行し、結果をクライアントに返します。Both SharePoint Framework and Script Editor Web Part solutions run in the browser and can contain only client-side JavaScript code. Client-side solutions have a number of limitations, such as not being able to elevate permissions in SharePoint or reach out to external APIs that don't support cross-origin communication (CORS) or authentication using OAuth implicit flow. In such cases, the client-side solution could leverage a remote server-side API to perform the necessary operation and return the results to the client.

SharePoint でソリューションをホストするHost solution in SharePoint

スクリプト エディター Web パーツを使用して SharePoint カスタマイズをビルドする 利点の1つは、コードを通常の SharePoint ドキュメント ライブラリでホストできるという点でした。One of the benefits of building SharePoint customizations using Script Editor Web Parts was the fact that their code could be hosted in a regular SharePoint document library. SharePoint アドインと比較して、必要なインフラストラクチャが少なく、ソリューションのホスティングが簡単でした。Compared to SharePoint Add-ins, it required less infrastructure and simplified hosting the solution. また、組織は SharePoint アクセス許可を使用してソリューション ファイルへのアクセスを制御できました。Additionally, organizations could use SharePoint permissions to control access to the solution files.

CDN における SharePoint Framework ソリューションのホスティングには多数の利点がありますが、必須ではありません。コードを通常の SharePoint ドキュメント ライブラリでホストするよう選択することもできます。While hosting SharePoint Framework solutions on a CDN offers a number of advantages, it is not required, and you could choose to host their code in a regular SharePoint document library. アプリ カタログに配置された SharePoint Framework パッケージ (.sppkg ファイル) により、SharePoint Framework がソリューションのコードを検出できる URL が指定されます。SharePoint Framework packages (.sppkg files) deployed to the app catalog specify the URL at which SharePoint Framework can find the solution's code. Web パーツが含まれるページを参照するユーザーが指定の場所から対象スクリプトをダウンロードできる限りは、指定する URL に制限はありません。There are no restrictions with regards to what that URL must be, as long as the user browsing the page with the web part on it can download the script from the specified location.

Office 365 に備わっているパブリック CDN 機能を使用すると、特定の SharePoint ドキュメント ライブラリから CDN にファイルを公開できます。Office 365 offers the public CDN capability that allows you to publish files from a specific SharePoint document library to a CDN. Office 365 のパブリック CDN では、CDN を使用する利点と、SharePoint ドキュメント ライブラリでコード ファイルをホストする簡便さのバランスがうまく保たれています。Office 365 public CDN strikes a nice balance between the benefits of using a CDN and the simplicity of hosting code files in a SharePoint document library. コード ファイルが公開されることを組織が問題にしない場合には、Office 365 のパブリック CDN の使用を検討する価値があります。If your organization doesn't mind their code files being publicly available, using the Office 365 public CDN is an option worth considering.

SharePoint Framework ソリューションとスクリプト エディター Web パーツ カスタマイズの相違点Differences between SharePoint Framework solutions and Script Editor Web Part customizations

SharePoint Framework およびスクリプト エディター Web パーツを使用してビルドされる SharePoint カスタマイズはとてもよく似ています。SharePoint customizations built using the SharePoint Framework and Script Editor Web Part are very similar. すべては、現在のユーザーのコンテキストでページのパーツとして実行され、クライアント側 JavaScript を使用してビルドされます。They all run as a part of the page under the context of the current user and are built using client-side JavaScript. ただし、いくつかの大きな違いもあり、アーキテクチャ上の決定に影響を及ぼすため、ソリューションの設計時に銘記しておく必要があります。But there are also some significant differences that might influence your architectural decisions and which you should keep in mind when designing your solution.

スクリプトなしのサイトで実行するRun in no-script sites

クライアント側のカスタマイズをスクリプト エディター Web パーツを使用してビルドする場合、カスタマイズを使用することになるサイトがスクリプトなしのサイトかどうかを考慮する必要がありました。When building client-side customizations using the Script Editor Web Part, you had to take into account whether the site where the customization would be used was a no-script site or not. サイトがスクリプトなしのサイトの場合、スクリプトなしの設定を無効にするよう管理者に要求するか、アドイン モデルを使用するなど別の方法でソリューションをビルドする必要がありました。If the site was a no-script site, you either had to request the admin to disable the no-script setting or build your solution differently, for example, by using the add-in model.

SharePoint Framework ソリューションは事前承認を受けたアプリ カタログ経由で配置されるため、スクリプトなしの制約を受けず、すべてのサイトで動作します。Because SharePoint Framework solutions are deployed through the app catalog with a prior approval, they are not subject to the no-script restrictions and work on all sites.

IT を利用して配置および更新するDeployed and updated through IT

スクリプト エディター Web パーツは主にシチズン・デベロッパーが SharePoint カスタマイズをビルドするために使用されてきました。Script Editor Web Parts are used to build SharePoint customizations primarily by citizen developers. シチズン・デベロッパーは、サイト所有者のアクセス許可さえあれば、ビジネス上の価値を付加できる魅力的な SharePoint カスタマイズをビルドできます。With nothing more than site owner permissions, citizen developers can build compelling SharePoint customizations that add business value. カスタマイズを更新する必要がある場合、必要なアクセス許可を持つユーザーはソリューションのスクリプト ファイルに更新を適用でき、すべてのユーザーが変更内容をすぐに確認できます。Whenever the customization needs to be updated, users with the necessary permissions can apply updates to the solution's script files and the changes are immediately visible to all users.

スクリプト エディター Web パーツ ソリューションの場合、使用されているカスタマイズの内容や使用されている場所を IT 組織が追跡することは困難です。さらに、どの外部スクリプトが組織のイントラネットで使用されていて、組織のデータにアクセスできるかを判断することもできません。Script Editor Web Part solutions make it hard for IT organizations to keep track of what customizations are being used and where they are being used. Additionally, organizations can't tell which external scripts are being used in their intranet and have access to their data.

SharePoint Framework は制御を IT に戻します。SharePoint Framework ソリューションはアプリ カタログで一元的に配置および管理されるため、組織はソリューションの配置前に確認する機会があります。さらに、すべての更新もアプリ カタログ経由で配置されるため、組織は検証および承認してから配置することができます。SharePoint Framework gives the control back to the IT. Because SharePoint Framework solutions are deployed and managed centrally in the app catalog, organizations have the opportunity to review the solution before deploying it. Additionally, any updates are deployed via the app catalog as well, allowing organizations to verify and approve them before deployment.

ユーザー エクスペリエンスの統一に重点を置くFocus more on uniform user experience

スクリプト エディター Web パーツを使用してカスタマイズをビルドする場合、シチズン・デベロッパーが自分のカスタマイズの DOM すべてを所有します。When building customizations using the Script Editor Web Part, citizen developers owned the complete DOM of their customization. ユーザー エクスペリエンスおよびカスタマイズの動作方法についてのガイドラインはありません。There were no guidelines related to the user experience and how such customization should work. その結果、さまざまな開発者が異なる方法でカスタマイズをビルドし、エンドユーザーのユーザー エクスペリエンスに整合性がなくなります。As a result, different developers built customizations in different ways, which led to an inconsistent user experience for end users.

SharePoint Framework の目標の 1 つはクライアント側カスタマイズのビルドを標準化することです。それにより、配置、保守、ユーザー エクスペリエンスの観点で統一できます。One of the goals of the SharePoint Framework is to standardize building client-side customizations so that they are uniform from the deployment, maintenance, and user experience point of view. Office UI Fabric を使用すると、開発者はカスタム ソリューションの外観と動作を SharePoint の一部であるかのようにすることが簡単にでき、ユーザーによる導入を容易にできます。Using Office UI Fabric, developers can more easily make their custom solutions look and behave like they are an integral part of SharePoint, simplifying user adoption. SharePoint Framework ツールチェーンによってソリューション用のパッケージ ファイルが生成されます。それを、アプリ カタログとスクリプト バンドルに配置し、選択したホスティング場所に配置します。SharePoint Framework toolchain generates package files for the solutions that are deployed to the app catalog, and script bundles that are deployed to the hosting location of your choice. すべてのソリューションは同じ方法で構造化され、管理されます。Every solution is structured and managed in the same way.

カスタマイズの外部で DOM を変更しないDon't modify DOM outside of the customization

従来、スクリプト エディター Web パーツを使用してページのパーツを変更すること、たとえば、ツールバーにボタンを追加したり、ページの見出しやブランドを変更したりすることがよくありました。Script Editor Web Parts were frequently used in the past to modify parts of the page, such as adding buttons to the toolbar or changing the heading or branding of the page. こうしたカスタマイズは特定の DOM 要素に依存し、SharePoint UI が更新されると、そうしたカスタマイズが壊れる可能性がありました。Such customizations relied on the existence of specific DOM elements, and whenever SharePoint UI would be updated, there was a chance that such customization would break.

SharePoint Framework では、SharePoint をカスタマイズするためにより構造化され、信頼性の高い方法が推奨されています。SharePoint Framework encourages a more structured and reliable approach to customizing SharePoint. 特定の DOM 要素を使用して SharePoint をカスタマイズするのではなく、SharePoint Framework に備わっているパブリック API を使用して、開発者は SharePoint を拡張できます。Rather than using specific DOM elements to customize SharePoint, SharePoint Framework provides developers with a public API that they can use to extend SharePoint. クライアント側 Web パーツが SharePoint Framework によってサポートされている唯一の形ですが、JSLink やユーザー カスタム アクションなどの他の形も今後使用できるように検討中で、SharePoint Framework を使用してほとんどの一般的なカスタマイズ シナリオを開発者が実装できるようにする予定です。Client-side web parts are the only shape supported by the SharePoint Framework, but other shapes, such as equivalents of JSLink and User Custom Actions, are being taken into consideration for the future so that developers can implement the most common customization scenarios by using the SharePoint Framew../ork.

パッケージとして配布されるDistributed as packages

SharePoint クライアント側カスタマイズではデータを格納するための SharePoint リストとライブラリが使用されます。スクリプト エディター Web パーツを使用してビルドする場合、必要な前提条件コンポーネントを自動的にプロビジョニングする簡単な方法はありませんでした。同じカスタマイズを別のサイトに配置するときには、多くの場合、Web パーツをコピーしますが、同時に必要なデータ ストレージを適切に再作成して保守しなければなりませんでした。SharePoint client-side customizations often used SharePoint lists and libraries to store their data. When built using the Script Editor Web Part, there was no easy way to automatically provision the necessary prerequisites. Deploying the same customization to another site often meant copying the web part but also correctly recreating and maintaining the necessary data storage.

SharePoint Framework ソリューションは、フィールド、コンテンツ タイプ、リストなどの前提条件を自動的にプロビジョニングできるパッケージとして配布されます。SharePoint Framework solutions are distributed as packages capable of provisioning their prerequisites, such as fields, content types, or lists, automatically. パッケージをビルドする開発者は、ソリューションで必要となる成果物を指定できます。サイトにインストールされると、指定した成果物が作成されます。Developers building the package can specify which artifacts are required by the solution, and whenever it's installed in a site, the specified artifacts are created. これにより、複数のサイトにおけるソリューションの配置と管理のプロセスが大幅に簡素化されます。This significantly simplifies the process of deploying and managing the solution on multiple sites.

より堅固なソリューションをビルドし、保守を簡単にするために TypeScript を使用するUse TypeScript for building more robust and easier to maintain solutions

スクリプト エディター Web パーツを使用してカスタマイズをビルドするとき、多くの場合、シチズン・デベロッパーはプレーンな JavaScript を使用してきました。When building customizations using the Script Editor Web Part, citizen developers often used plain JavaScript. そのようなソリューションには自動化されたテストが含まれておらず、コードのリファクタリングでエラーが生じやすい場合が少なくありませんでした。Often such solutions didn't contain any automated tests, and refactoring the code was error-prone.

SharePoint Framework を使用すると、開発者はソリューションのビルド時に TypeScript 型のシステムの利点を生かすことができます。SharePoint Framework allows developers to benefit from the TypeScript type system when building solutions. この型のシステムにより、実行時ではなく、開発中にエラーをキャッチできます。Thanks to the type system, errors are caught during development rather than on runtime. また、コードのリファクタリングも簡単に実行できます。TypeScript によってコードに対する変更がセーフガードされるためです。Also, refactoring code can be done more easily as changes to the code are safeguarded by TypeScript. すべての JavaScript が有効な TypeScript であるため、エントリ障壁が低く、プレーンな JavaScript を時間の経過とともに徐々に TypeScript に移行し、ソリューションの保守能力を向上させていくことができます。Because all JavaScript is valid TypeScript, the entry barrier is low and you can migrate your plain JavaScript to TypeScript gradually over time increasing the maintainability of your solution.

spPageContextInfo オブジェクトに依存できないCan't rely on the spPageContextInfo object

従来は、開発者が再利用可能なクライアント側カスタマイズをビルドする場合、spPageContextInfo JavaScript オブジェクトを使用して、現在のページ、サイト、ユーザーに関する情報を取得しました。When building reusable client-side customizations, in the past developers used the spPageContextInfo JavaScript object to get information about the current page, site, or user. このオブジェクトにより、SharePoint 内の異なるサイトでソリューションを再利用可能にする方法が提供され、固定の URL を使用する必要はありませんでした。This object offered them an easy way to make their solution reusable across the different sites in SharePoint and not have to use fixed URLs.

spPageContextInfo オブジェクトが依然としてクラシック SharePoint ページ上にある間は、SharePoint モダン ページとライブラリで信頼して使用することはできません。While the spPageContextInfo object is still present on classic SharePoint pages, it cannot be reliably used with modern SharePoint pages and libraries. SharePoint Framework でソリューションをビルドする際に、開発者は IWebPartContext.pageContext オブジェクトを代わりに使用することをお勧めします。このオブジェクトには、特定のソリューションのコンテキスト情報が含まれています。When building solutions on the SharePoint Framework, developers are recommended to use the IWebPartContext.pageContext object instead, which contains the context information for the particular solution.

既定では SharePoint JavaScript オブジェクト モデルにアクセスできないNo access to SharePoint JavaScript Object Model by default

SharePoint クラシック ユーザー エクスペリエンス向けのクライアント側カスタマイズをビルドする場合、多くの開発者は JavaScript オブジェクト モデル (JSOM) を使用して SharePoint と通信しました。When building client-side customizations for the classic SharePoint user experience, many developers used the JavaScript Object Model (JSOM) to communicate with SharePoint. JSOM により、クライアント側オブジェクト モデル (CSOM) と同じような方法で、SharePoint API に対して IntelliSense と簡単なアクセスが提供されてきました。JSOM offered them intellisense and easy access to the SharePoint API in a way similar to the Client-Side Object Model (CSOM). 従来の SharePoint ページでは、JSON のコア要素は既定でページ上に存在し、開発者は、SharePoint Search との通信などのために追加要素を読み込むことができました。In classic SharePoint pages, the core piece of JSOM was by default present on the page, and developers could load additional pieces to communicate with SharePoint Search, for example.

既定では、SharePoint モダン ユーザー エクスペリエンスには SharePoint JSOM は含まれていません。The modern SharePoint user experience doesn't include SharePoint JSOM by default. 開発者自身で読み込むことができますが、代わりに REST API を使用することが推奨されています。While developers can load it themselves, the recommendation is to use the REST API instead. REST の使用は、jQuery、Angular、React などの異なるクライアント側ライブラリ間でより汎用的で交換可能です。Using REST is more universal and interchangeable between the different client-side libraries such as jQuery, Angular, or React.

Microsoft はこれ以上 JSOM に関して積極的な投資は行いません。Microsoft is not actively investing in JSOM anymore. API を使用して作業する場合、SharePoint のパターンとプラクティスに関する JavaScript コア ライブラリを代わりに使用できます。このライブラリでは、Fluent API と TypeScript 型指定が提供されます。If you prefer working with an API, you could alternatively use the SharePoint Patterns and Practices JavaScript Core Library, which offers you a fluent API and TypeScript typings.

既存のカスタマイズを SharePoint Framework に移行するMigrate existing customization to the SharePoint Framework

既存のスクリプト エディター Web パーツのカスタマイズを SharePoint Framework に移行すると、エンドユーザーと開発者の両方に多数の利点があります。Migrating existing Script Editor Web Part customizations to the SharePoint Framework offers both end-users and developers a number of benefits. 既存のカスタマイズを SharePoint Framework に移行することを検討する場合、既存のスクリプトのほとんどを再利用するのか、カスタマイズを完全に再作成するのかを選択できます。When considering migrating existing customizations to the SharePoint Framework, you can choose to either reuse as much of the existing scripts as possible or completely rewrite the customization.

既存のスクリプトを再利用するReuse existing scripts

既存のスクリプト エディター Web パーツのカスタマイズを SharePoint Framework に移行する場合、既存のスクリプトを再利用するように選択することもできます。When migrating existing Script Editor Web Part customizations to the SharePoint Framework, you can choose to reuse your existing scripts. SharePoint Framework では TypeScript の使用が推奨されていますが、プレーンな JavaScript を使用して徐々に TypeScript に変換していくこともできます。Even though the SharePoint Framework encourages using TypeScript, you can use plain JavaScript and gradually transform it to TypeScript. 特定のソリューションを限られた期間だけサポートする必要がある場合や、予算が限られている場合には、この方法が適していることもあります。If you need to support a particular solution for a limited period of time or have a limited budget, this approach might be good enough for you.

SharePoint Framework ソリューションで既存のスクリプトを再利用することはいつでも可能とは限りません。Reusing existing scripts in a SharePoint Framework solution is not always possible. たとえば、SharePoint Framework ソリューションを JavaScript モジュールとしてパッケージ化し、ページ上で非同期的に読み込む場合があります。SharePoint Framework solutions, for example, are packaged as JavaScript modules and load asynchronously on a page. 一部の JavaScript ライブラリはモジュールで参照される場合に正常に動作せず、特定の方法で参照する必要があります。Some JavaScript libraries don't work correctly when referenced in a module or have to be referenced in a specific way. さらに、onload などのページ イベントに依存したり、jQuery ready 関数を使用したりすると、望ましくない結果になることがあります。Additionally, relying on page events such as onload or using the jQuery ready function might lead to undesirable results.

JavaScript ライブラリが多様であることを考えると、既存のスクリプトを SharePoint Framework ソリューションで再利用できるか、結局再作成する必要があるかを簡単に見極める方法はありません。Given the variety of JavaScript libraries, there is no easy way to tell upfront if your existing scripts can be reused in a SharePoint Framework solution or if you need to rewrite it after all. 見極める唯一の方法は、さまざまな部分を SharePoint Framework ソリューションに移行し、正常に動作するかどうか確認することです。The only way to determine this is by trying to move the different pieces to a SharePoint Framework solution and see if they work as expected.

カスタマイズを再作成するRewrite the customization

ソリューションを長期にわたりサポートする必要がある場合、SharePoint Framework を有効活用したい場合や、既存のスクリプトを SharePoint Framework で再利用できないことがわかった場合には、カスタマイズを完全に再作成しなければならないことがあります。If you need to support your solution for a longer period of time, would like to make better use of the SharePoint Framework, or if it turns out that your existing scripts cannot be reused with the SharePoint Framework, you might need to completely rewrite your customization. 既存のスクリプトを再利用するよりもコストが高くなりますが、長い目で見るとより良い結果が得られ、ソリューションのパフォーマンスは向上し、保守と使用が簡単になります。While it's more costly than reusing existing scripts, it offers you better results over a longer period of time: a solution that is better performing, and easier to maintain and use.

既存のスクリプト エディター Web パーツのカスタマイズを SharePoint Framework ソリューションに再作成するときは、まず必要な機能に注意を払ってください。When rewriting an existing Script Editor Web Part customization to a SharePoint Framework solution, you should start with the desired functionality in mind. ユーザー エクスペリエンスを実装するため、Office UI Fabric の使用を検討してください。それにより、ソリューションが SharePoint の不可欠な部分のようになります。For implementing the user experience, you should consider using the Office UI Fabric so that your solution looks like an integral part of SharePoint. グラフやスライドなどの特定のコンポーネントに関しては、モジュールとして配布され、TypeScript 型指定を持つモダン ライブラリを探してください。For specific components such as charts or sliders, you should try looking for modern libraries that are distributed as modules and have TypeScript typings. そうしたライブラリを使用すると、ソリューションに簡単にコンポーネントを統合できるようになります。This makes it easier for you to integrate the component in your solution.

特定のシナリオで使用する最適なコンポーネントはどれかについて答えは 1 つではありませんが、SharePoint Framework はほとんどの一般的なシナリオに十分対応でき、既存のクライアント側カスタマイズを完全に機能の揃った SharePoint Framework ソリューションに変換できます。While there is no single answer as to which component is the best to use for which scenario, the SharePoint Framework is flexible enough to accommodate most popular scenarios, and you should be able to transform your existing client-side customizations into fully-featured SharePoint Framework solutions.

移行のヒントMigration tips

既存のスクリプト エディター Web パーツのカスタマイズを SharePoint Framework に変換するときは、いくつかの一般的なパターンがあります。When transforming existing Script Editor Web Part customizations to the SharePoint Framework, there are a few common patterns.

既存のコードを SharePoint Framework に移動するMove existing code to SharePoint Framework

スクリプト エディター Web パーツを使用してビルドする SharePoint カスタマイズは多くの場合、Web パーツに含まれるいくつかの HTML マークアップと、JavaScript ファイルへの 1 つ以上の参照で構成されます。SharePoint customizations built using the Script Editor Web Part often consist of some HTML markup, included in the web part, and one or more references to JavaScript files. 既存のカスタマイズを SharePoint Framework ソリューションに変換する場合には、スクリプト エディター Web パーツの HTML マークアップを、SharePoint Framework クライアント側 Web パーツの render メソッドに移行しなければならない可能性が高くなります。When transforming your existing customization to a SharePoint Framework solution, the HTML markup from the Script Editor Web Part would most likely have to be moved to the render method of the SharePoint Framework client-side web part. 外部スクリプトへの参照は、** config.json** ファイルの cexternals プロパティ内の参照に変更します。References to external scripts would be changed to references in the externals property in the config.json file. 内部スクリプトは、Web パーツ ソース フォルダーにコピーされ、require() ステートメントを使用して Web パーツ クラスから参照されます。Internal scripts would be copied to the web part source folder and referenced from the web part class by using require() statements.

スクリプト ファイルから関数を参照するReference functions from script files

スクリプト ファイルから関数を参照するには、これらの関数をエクスポートとして定義する必要があります。To reference functions from script files, these functions need to be defined as an export. SharePoint Framework クライアント側 Web パーツで使用する、既存の JavaScript ファイルについて検討しましょう。Consider an existing JavaScript file that you would like to use in a SharePoint Framework client-side web part:

var greeting = function() {
  alert('How are you doing?');
  return false;
}

Web パーツ クラスから greeting 関数を呼び出せるようにするため、JavaScript ファイルを次のように変更する必要があります。To be able to call the greeting function from the web part class, you would need to change the JavaScript file to:

var greeting = function() {  
  alert('How are you doing?');
  return false;
}

module.exports = {  
  greeting: greeting
};

次に、Web パーツ クラスでこのスクリプトを参照し、greeting 関数を呼び出せます。Then, in the web part class, you can refer to the script and call the greeting function:

public render(): void {  
  this.domElement.innerHTML = `
    <input type="button" value="Click me"/>`;

  const myScript = require('./my-script.js');
  this.domElement.querySelector('input').addEventListener('click', myScript.greeting);
}

AJAX 呼び出しを実行するExecute AJAX calls

多くのクライアント側カスタマイズでは、わかりやすさやブラウザー間の互換性を確保するために、AJAX 要求の実行用に jQuery を使用します。Many client-side customizations use jQuery for executing AJAX requests for its simplicity and cross-browser compatibility. jQuery を使用する目的がその点だけに限られている場合、SharePoint Framework に備わっている標準の HTTP クライアントを使用して、AJAX 呼び出しを実行できます。If this is all that you're using jQuery for, you can execute the AJAX calls by using the standard HTTP client provided with the SharePoint Framework.

SharePoint Framework には 2 つの種類の HTTP クライアント、つまり SPHttpClient (SharePoint REST API に対する要求の実行用) と HttpClient (他の REST API に対する Web 要求の発行用) が備わっています。SharePoint Framework offers you two types of HTTP client: the SPHttpClient, meant for executing requests to the SharePoint REST API, and the HttpClient designed for issuing web requests to other REST APIs. SPHttpClient を使用して、現在の SharePoint サイトのタイトルを取得する呼び出しの実行方法を次に示します。Here is how you would execute a call by using the SPHttpClient to get the title of the current SharePoint site:

this.context.spHttpClient.get(`${this.context.pageContext.web.absoluteUrl}/_api/web?$select=Title`,
SPHttpClient.configurations.v1,
{
  headers: {
    'Accept': 'application/json;odata=nometadata',
    'odata-version': ''
  }
})
.then((response: SPHttpClientResponse): Promise<{Title: string}> => {
  return response.json();
})
.then((web: {Title: string}): void => {
  // web.Title
}, (error: any): void => {
  // error
});

関連項目See also