編輯頁面

升級至 Sails v0.11

概要；

v0.11 帶來了許多小的改進，以及核心內部的一些清理。最大的改變是 Sails 核心現在使用 Socket.io v1。

幾乎所有這些都不應影響專案中現有的程式碼，但有一些重要的差異和新功能需要注意。我們在下面列出了它們。

差異

升級 Socket.io / Sails.io 瀏覽器用戶端

舊的 v0.9 socket.io 用戶端將不再運作，因此您需要將 sails.io.js 用戶端從 v0.9 或 v0.10 升級到 v0.11。

要執行此操作，只需移除您的 sails.io.js 用戶端並安裝新的用戶端。我們捆綁了一個新的產生器，它會為您執行此操作，假設您的 sails.io.js 用戶端位於傳統位置 assets/js/dependencies/sails.io.js（即，如果您沒有移動或重新命名它）

sails generate sails.io.js --force

onConnect 生命周期回呼

概要；

從 config/sockets.js 中移除您的 onConnect 函數。

onConnect 生命周期回呼已被棄用。相反地，如果您需要在新 socket 連線時執行某些操作，請從新連線的用戶端發送請求來執行此操作。onConnect 的目的始終是為了優化效能（消除與伺服器進行初始額外往返的需求），但其使用可能會導致混淆和競爭條件。如果您迫切需要消除伺服器往返，您可以直接在 bootstrap 函數 (config/bootstrap.js) 中的 sails.io.on('connect', function (newlyConnectedSocket){}) 上綁定處理常式。但是，請注意，不建議這樣做。除非您面臨真正的生產環境效能問題，否則您應該使用上述策略來處理您的「連線時」邏輯（即，在 socket 連線後從用戶端發送初始請求）。Socket 請求是輕量級的，因此這不會為您的應用程式增加任何實際的額外負擔，並且它將有助於使您的程式碼更具可預測性。

onDisconnect 生命周期回呼

onDisconnect 生命周期回呼已被棄用，改用 afterDisconnect。

如果您之前使用過 onDisconnect，您可能必須更改 session，然後手動呼叫 session.save()。在 v0.11 中，這幾乎以完全相同的方式運作，只是 afterDisconnect 接收到額外的第三個引數：一個回呼函數。這樣，您可以在 afterDisconnect 邏輯完成後呼叫提供的回呼，以便 Sails 可以自動持久化您對 session 所做的任何更改。最後，正如您可能預期的那樣，您不再需要手動呼叫 session.save() - 現在已為您處理（就像一般路由、動作或策略中的 req.session 一樣）。

概要； 將 config/sockets.js 中的 onDisconnect 函數重新命名為以下內容

afterDisconnect: function (session, socket, cb) {
 // Be sure to call the callback
 return cb();
}

config/sockets.js 中的其他設定

Socket.io v1 中的許多設定選項已更改，因此您需要相應地更新您的 config/sockets.js 檔案。

• 如果您沒有為您的應用程式自訂 config/sockets.js 中的任何選項，您可以安全地移除或註解掉整個檔案，讓 Sails 預設值發揮作用。否則，請參閱新的 Sails sockets 文件，以確保您的設定仍然有效並避免不必要的脫髮。
• 如果您要擴展到不支援黏性會話的環境中的多個伺服器（包括 Heroku），您需要在 config/socket.js 和您的用戶端中將 transports 設定為 ['websocket'] - 請參閱 我們的擴展文件 以取得更多資訊。
• 如果您使用自訂 authorization 函數來限制 socket 連線，您現在需要使用 beforeConnect。authorization 已被 Socket.io v1 棄用，但 beforeConnect（對應到 Engine.io 的 allowRequest 選項）的工作方式完全相同。
• 如果您使用其他直接傳遞到 socket.io v1 的低階 socket 設定，請務必查看 sailsjs.com 上的參考頁面，其中詳細介紹了所有新的設定選項。

「消防水帶」

用於 socket 測試的「消防水帶」功能已被棄用。如果您不知道這意味著什麼，您不必擔心。基本用法將在一段時間內繼續運作，但很快將從核心中移除，不應在您的應用程式中依賴它。這也適用於以下方法

• sails.sockets.subscribeToFirehose()
• sails.sockets.unsubscribeFromFirehose()
• sails.sockets.drink()
• sails.sockets.spit()
• sails.sockets.squirt()

如果您想要恢復「消防水帶」，請在 Twitter 上告訴 Mike（它可以作為一個單獨的 hook 帶回）。

子資料夾中的設定檔

Sails config 資料夾中的檔案始終不應優先於彼此，並且檔名和子資料夾（local.js 以及 env 和 locale 子資料夾除外）僅用於組織。但是，在之前的 Sails 版本中，將設定檔儲存在子資料夾中會產生檔名作為 sails.config 中的鍵添加的效果，因此如果您將一些設定儲存在 config/foo/bar.js 中，那麼該設定將在 sails.config.bar 下命名空間。這是無意的，並且可能會造成混淆，因為 1) 目錄名稱被忽略，並且 2) 移動檔案會更改設定鍵。這已在 v0.11.x 中修復：子資料夾中的設定檔將與根 config 資料夾中的檔案相同對待。如果您因某種原因依賴舊的行為，您可以在 .sailsrc 檔案中將 dontFlattenConfig 設定為 true，但我們強烈建議您改為透過在 module.exports 上設定所需的鍵來自行命名空間設定；例如 module.exports.foo = {...}。請參閱 issue #2544 以取得更多詳細資訊。

Waterline 現在使用 Bluebird

從 v0.11 開始，Waterline 現在支援 Bluebird（而不是 q）用於 promise。如果您使用 .exec()，您將不會受到影響 - 僅當您使用 .then() 時才會受到影響。請參閱 https://github.com/balderdashy/sails/issues/1186 以取得更多資訊。

新功能

Sails v0.11 也帶有一些我們認為您會想知道的新東西

使用者層級的 hooks

現在可以直接從 NPM 安裝 Hooks。

這意味著您現在可以使用單個命令在終端機中安裝 hook。例如，考慮 autoreload hook 由 @sgress454 提供，它會監看後端程式碼的變更，因此您每次更改控制器、路由、模型等時都不需要終止並重新啟動伺服器。

要安裝 autoreload hook，請執行

npm install sails-hook-autoreload

這僅僅是可能性的示例之一。正如您可能已經知道的那樣，hooks 是 Sails 中最低層級的可插拔抽象。它們允許作者利用啟動過程、監聽事件、注入自訂「影子」路由，並且通常利用對 sails 執行時的原始存取權限。您在 Sails 中熟悉的大多數功能實際上已經作為「核心」hook 實作了一年多，包括

• blueprints （提供藍圖 API）
• sockets （提供 socket.io 整合）
• grunt （提供 Grunt 整合）
• orm （提供與 Waterline ORM 的整合，並匯入您的專案 adapters、models 等）
• http （提供 HTTP 伺服器）
• 以及其他 16 個。

您可以在 新的和改進的「擴展 Sails」文件中閱讀有關如何編寫自己的 hook 的更多資訊，網址為 https://sails.dev.org.tw。

Socket.io v1.x

升級到 Socket.io v1.0 實際上不應影響您的應用程式層級程式碼，前提是您使用的是 Sails 本身提供的抽象層；從 sails.sockets.* wrapper 方法和「向上」（資源豐富的 pubsub、藍圖）的所有內容。如果您在您的應用程式中使用底層 socket.io 方法，或者只是好奇 Socket.io v1.0 中發生了什麼變化，請務必查看 Guillermo 和 socket.io 團隊的 完整的 Socket.io 1.0 遷移指南。

不斷提高的模組化

作為升級到 Socket.io v1.0 的一部分，我們將核心 sockets hook 拉出到一個單獨的儲存庫中。這使我們能夠為 socket.io 解釋器編寫一些模組化、特定於 hook 的測試，這將使維護、自訂和覆蓋變得更容易。這也允許 hook 以自己的速度增長，並將相關問題放在一個地方。

將此視為在接下來的幾個月內將其他 hook 從 sails 核心儲存庫中拉出的優缺點的測試。這將使 Sails 核心更輕、更快、更具可擴展性，具有更少的核心依賴項，大多數應用程式的「啟動」時間更短，以及更快的 npm install。

測試、「虛擬」請求解釋器和 sails.request() 方法

在將 sockets hook 拉出核心的過程中，解釋請求的邏輯已被標準化，現在位於 Sails 核心內部。因此，sails.request() 方法變得更加強大。

此方法允許您直接與 Sails 中的請求解釋器進行通訊，而無需將伺服器啟動到埠上。它與 Sails 用於將來自 Socket.io 的傳入訊息對應到具有熟悉的 req 和 res 串流的「虛擬請求」的機制相同。

sails.request() 的主要用例是編寫更快執行的單元測試和整合測試，但它也適用於代理到已掛載的應用程式（或「子應用程式」）。

例如，以下是如何測試您的應用程式的路由之一的範例（使用 mocha）

var assert = require('assert');
var Sails = require('sails').Sails;

before(function beforeRunningAnyTests (done){

  // Load the app (no need to "lift" to a port)
  sails.load({
    log: {
      level: 'warn'
    },
    hooks: {
      grunt: false
    }
  }, function whenAppIsReady(err){
    if (err) return done(err);

    // At this point, the `sails` global is exposed, although we
    // could have disabled it above with our config overrides to
    // `sails.load()`. In fact, you can actually use this technique
    // to set any configuration setting you like.
    return done();
  });
});

after(function afterTestsFinish (done) {
  sails.lower(done);
});

describe('GET /hotpockets', function (){

  it('should respond with a 200 status code', function (done){

    sails.request({
      method: 'get',
      url: '/hotpockets',
      params: {
        limit: 10,
        sort: 'price ASC'
      }
    }, function (err, clientRes, body) {
      if (err) return done(err);

      assert.equal(clientRes.statusCode, 200);
      return done();
    });

  });
});

config/env/ 子資料夾

在 v0.10.x 中，我們新增了 config/env 資料夾（感謝 @clarkorz），您可以在其中新增僅在適當環境中載入的設定檔（例如，生產環境的 config/env/production.js，開發環境的 config/env/development 等）。在 v0.11.x 中，我們新增了為每個環境指定整個子資料夾的功能。例如，儲存到 config/env/production 的所有設定檔將在環境設定為 production 時載入並合併到其他設定之上。請注意，如果同時存在 config/env/production 資料夾和 config/env/production.js 檔案，則 config/env/production.js 設定將優先。而且，與往常一樣，local.js 會合併到所有其他檔案之上，而 .sailsrc 規則適用於所有檔案。

有問題嗎？

與往常一樣，如果您在升級時遇到問題，或者如果上面的任何注意事項沒有意義，請告知我們，我們會盡力澄清。

最後，對於自 8 月 v0.10 版本發布以來為專案做出貢獻的各位：我們再怎麼強調都無法表達我們有多麼重視您們持續的支持和鼓勵。問題、pull request、文件調整和問題的 поток 非常龐大，但始終知道我們在一起會有所幫助 :)

謝謝。

-@mikermcneil、@sgress454 和 @particlebanana