SharePoint Framework と SharePoint 2013 クライアント開発でこれから意識したいこと

2017年の後半に、SharePoint Framework (SPFx) という新しい開発モデルが出ていました。
SharePoint Framework の概要 (SPFx) | Microsoft Docs

すごくざっくり言うと、SharePointでもモダンなWeb開発が始まる、というものです。
任意のJavaScript フレームワーク利用やオープンソースの開発ツールのチェイン等を謳っています。

ただ、対象は SharePoint Online とオンプレミスの SharePoint 2016 Feature Pack 2 なので、
SharePoint 2013の環境等では適用されません。

適用対象外ではあるのですが、将来的なバージョンアップを考慮するならば、
オンプレミスの SharePoint 2013 クライアント開発でも意識したいことがあります。

それは、SharePoint JSOM の積極的な利用をやめることです。

クライアントからSharePointとの通信を行う場合、
現在は SharePoint REST API か sp-pnp-js ライブラリ(REST API ラッパー)の利用が推奨されています。

もちろん、JSOM のコードは自体は依然有効ではあるのですが、
非推奨・下位互換性のために残されているような API を使い続ける必要性は薄いでしょう。

――と自分で書いていながら、衝撃の事実に震えています。もっと早くその方向性を示して欲しかった。

JSOM は SSOM(サーバーサイドAPI)に精通していれば手軽に使える(似ている)ので、
ある程度 SharePoint開発に携わっていると、RESTよりもJSOMを選択してしまうことが多いのではと思います。

悲観していても仕方がないので、SharePoint REST API を積極的に利用し始めました。
sp-pnp-js ライブラリを活用しても良いのですが、いったんは様子見です。
IE 11だと Promise や fetch の Polyfill が必須だとか、その他もろもろの理由で。

でも、REST をそのまま使うのも微妙なところです。

呼び出し毎に共通的な設定を都度行うくらいなら(ヘッダーとか)、
軽めにラップしたライブラリを使いたい。そんな理由で作りました。

jQuery.ajax に依存するのも XMLHttpRequest を直接使うのも避けたかったので、
クロスドメイン用ライブラリの SP.RequestExecutor.js を利用しています。

よろしければ自己責任でご利用ください。

kooh-q-hook