天天看點

SharePoint Framework 在web部件中使用已存在的JavaScript庫 - JavaScript庫的格式

JavaScript庫格式

不同的JavaScript庫的編譯和打包方式各不相同。一些是以子產品的方式打包的,而另一些是以純腳本運作在全局的方式。當從URL加載JavaScript庫時,你要如何注冊外部腳本取決于腳本的格式。腳本的格式有許多中:AMD、UMD或CommonJS,但隻需要知道該腳本是不是一個子產品即可。

在注冊打包為子產品的腳本時,唯一需要做的事情是指定特定腳本需要從哪個URL加載。另一方面,非子產品化腳本需要最小範圍腳本的URL(即.min.js)和全局名稱變量。舉個例子,Angular v1.x是一個非子產品化腳本,我們在SPFx項目中将它注冊為外部資源,用如下代碼指定它的URL和全局名稱:

"angular": {

"path": "https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.8/angular.min.js",

"globalName": "angular"

}

指定globalName屬性的值很重要,它與腳本使用的名稱一緻。這樣使腳本能夠正确地将自己暴露給其他依賴它的東西。

ngOfficeUIFabric - 一個依賴Angular的UMD子產品。由于已經在子產品内進行了依賴處理,在注冊它時你隻需要指定URL:

"ng-office-ui-fabric": "https://cdnjs.cloudflare.com/ajax/libs/ngOfficeUiFabric/0.12.3/ngOfficeUiFabric.js"

jQuery時一個AMD腳本,注冊它比較簡單,即

"jquery": "https://code.jquery.com/jquery-2.2.4.js"

現在想象一下,你想要使用jQuery中的一個插件,它時一個非子產品化腳本,這時如果使用以下代碼進行注冊:

"jquery": "https://code.jquery.com/jquery-2.2.4.js",

"simpleWeather": {

"path": "https://cdnjs.cloudflare.com/ajax/libs/jquery.simpleWeather/3.1.0/jquery.simpleWeather.min.js",

"globalName": "jQuery"

加載web部件很可能會發生錯誤,因為有可能兩個腳本是并行加載的,插件無法進行注冊。

之前提到過,SPFx允許你指定非子產品化插件的依賴關系。這些依賴在globalDependencies屬性中設定:

"globalName": "jQuery",

"globalDependencies": [ "jquery" ]

每一個依賴必須指向config/config.json檔案中的externals部分。

現在如果你想要編譯項目,你會遇到另一個錯誤,提示你不能依賴非子產品化腳本。

SharePoint Framework 在web部件中使用已存在的JavaScript庫 - JavaScript庫的格式

要解決這個問題,你需要注冊jQuery為非子產品化腳本:

"jquery": {

"path": "https://code.jquery.com/jquery-2.1.1.min.js",

},

這樣simpleWeather腳本就會在jQuery加載之後在自行注冊了。

很難手工判斷想要加載的腳本是子產品化還是非子產品化腳本,特别是最小化的腳本。如果你的腳本在一個公網URL承載,你可以使用免費的Rencore SharePoint Framework Script Check工具來确定腳本的類型。而且,該工具讓你能夠知道承載腳本的位置是否正确配置。

非子產品化腳本的考慮

許多JavaScript庫和腳本是非子產品化腳本。雖然SPFx支援加載非子產品化腳本,你還是應該避免去使用它們。

非子產品化腳本在頁面的全局被注冊:一個web部件加載的腳本對頁面上的其他web部件都可用。如果你有兩個web部件使用了不同版本的jQuery并且都加載為非子產品化腳本,最後加載的web部件會覆寫之前加載的jQuery版本。你能想象,這可能會導緻不可預見的結果并且不容易調試問題。子產品結構通過隔離腳本并防止它們互相影響解決了這個問題。

什麼時候考慮捆綁打包

捆綁打包已存在的JavaScript庫到你的web部件會生成尺寸較大的web部件檔案,導緻頁面的低性能。盡管我們應該避免這樣使用,但一些情況下還是有優勢的。

如果你編譯一個标準的解決方案,這個解決方案會在很多内網運作,那麼整體捆綁打包會幫助你確定你的web部件會正确工作,因為你不知道你的解決方案安裝在哪裡,不知道那裡能不能從外部資源加載腳本,那麼整體打包就會確定你引用的資源都可以成功加載到。

如果你的解決方案由許多web部件組成,有一些共享的函數,那麼可以考慮将這些共享的函數單獨編譯成庫并作為外部資源在所有web部件中引用。

總結

通過前面一篇和本篇,在編譯用戶端web部件時,SPFx允許我們捆綁打包将這些庫跟web部件打包到一起,或者作為外部資源加載。雖然從外部URL加載已存在的庫是推薦的方式,還是有一些情況采用捆綁打包更适合。

繼續閱讀