编辑页面

升级到 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 生命周期回调已被弃用。相反，如果您需要在连接新套接字时执行某些操作，请从新连接的客户端发送请求以执行此操作。onConnect 的目的是始终用于优化性能（消除执行此初始额外往返服务器的需要），但其使用会导致混淆和竞争条件。如果您迫切需要消除服务器往返，您可以在 config/bootstrap.js 的引导函数中直接在 sails.io.on('connect', function (newlyConnectedSocket){}) 上绑定处理程序。但是，请注意，不鼓励这样做。除非您面临真正的生产性能问题，否则您应该对您的“连接”逻辑使用上面提到的策略（即，在套接字连接后从客户端发送初始请求）。套接字请求很轻量级，因此这不会给您的应用程序增加任何实际开销，并且它将有助于使您的代码更易于预测。

onDisconnect 生命周期回调

onDisconnect 生命周期回调已被弃用，取而代之的是 afterDisconnect。

如果您之前使用过 onDisconnect，您可能需要更改 session，然后手动调用 session.save()。在 v0.11 中，这几乎以完全相同的方式工作，除了 afterDisconnect 接收一个额外的第三个参数：一个回调函数。这样，您只需在 afterDisconnect 逻辑完成后调用提供的回调，以便 Sails 可以自动持久化您对会话所做的任何更改。最后，正如您可能预期的那样，您不再需要手动调用 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 套接字文档 以确保您的配置仍然有效并避免不必要的脱发。
• 如果您在一个不支持粘性会话的环境中扩展到多台服务器（包括 Heroku），则需要在 config/socket.js 和您的客户端中将您的 transports 设置为 ['websocket'] - 请参阅 我们的扩展文档 以获取更多信息。
• 如果您使用自定义 authorization 函数来限制套接字连接，您现在需要使用 beforeConnect。authorization 已被 Socket.io v1 弃用，但 beforeConnect（映射到 Engine.io 的 allowRequest 选项）的工作方式完全相同。
• 如果您使用其他直接传递给 socket.io v1 的低级套接字配置，请务必查看 sailsjs.com 上的参考页面，其中所有新的配置选项都进行了详细介绍。

“消防水带”

用于使用套接字进行测试的“消防水带”功能已被弃用。如果您不知道这是什么意思，您无需担心。基本用法将在一段时间内继续有效，但很快将从核心代码中删除，并且不应在您的应用程序中依赖它。这也适用于以下方法

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

如果您想要“消防水带”回来，请在 推特上告诉 Mike（它可以作为单独的钩子恢复）。

子文件夹中的配置文件

一直以来，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 = {...}。有关更多详细信息，请参阅 问题 #2544。

Waterline 现在使用 Bluebird

从 v0.11 开始，Waterline 现在支持 Bluebird（而不是 q）用于 Promise。如果您使用的是 .exec()，您将不会受到影响 - 只有在您使用 .then() 时才会受到影响。有关更多信息，请参阅 https://github.com/balderdashy/sails/issues/1186。

新功能

Sails v0.11 还提供了一些我们认为您想知道的新内容

用户级钩子

钩子现在可以直接从 NPM 安装。

这意味着您现在可以在终端中使用单个命令安装钩子。例如，考虑 autoreload 钩子，它监视您后端代码的更改，因此您无需每次更改控制器、路由、模型等时都终止并重新启动服务器。

要安装 autoreload 钩子，请运行

npm install sails-hook-autoreload

这只是一个可能的例子。正如您可能已经知道的那样，钩子是 Sails 中最低级的可插拔抽象。它们允许作者利用提升过程，侦听事件，注入自定义“影子”路由，并且通常利用对 sails 运行时的原始访问。您在 Sails 中熟悉的大多数功能实际上已经作为“核心”钩子实现了超过一年，包括

• blueprints （提供蓝图 API）
• sockets （提供 socket.io 集成）
• grunt （提供 Grunt 集成）
• orm （提供与 Waterline ORM 的集成，并导入项目的适配器、模型等）
• http （提供 HTTP 服务器）
• 以及其他 16 个。

您可以在 Sailsjs.com 上新的和改进的“扩展 Sails”文档 中阅读有关如何编写自己的钩子的更多信息。

Socket.io v1.x

升级到 Socket.io v1.0 实际上不应该影响您的应用程序级代码，前提是您使用的是 Sails 本身提供的抽象层；从 sails.sockets.* 包装器方法和“向上”（资源丰富的发布/订阅、蓝图）开始如果您在应用程序中使用底层 socket.io 方法，或者只是好奇 Socket.io v1.0 中发生了哪些变化，请务必查看 Guillermo 和 socket.io 团队的 完整的 Socket.io 1.0 迁移指南。

不断增强的模块化

作为升级到 Socket.io v1.0 的一部分，我们将核心 sockets 钩子提取到一个单独的存储库中。这使我们能够为 socket.io 解释器编写一些模块化、特定于钩子的测试，这将使维护、自定义和覆盖变得更容易。这也允许钩子以自己的速度增长，并将相关问题放在一个地方。

可以将其视为在未来几个月内将其他钩子从 sails 核心存储库中提取的利弊的测试。这将使 Sails 核心更轻、更快、更具可扩展性，具有更少的核心依赖项，大多数应用程序的“提升”时间更短，以及更快的 npm install。

测试、“虚拟”请求解释器和 sails.request() 方法

在将 sockets 钩子从核心中提取的过程中，解释请求的逻辑已标准化，现在位于 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 中，我们添加了能够为每个环境指定整个子文件夹的功能。例如，当环境设置为 production 时，将加载并合并保存到 config/env/production 的所有配置文件。请注意，如果同时存在 config/env/production 文件夹和 config/env/production.js 文件，则 config/env/production.js 设置将优先。并且，像往常一样，local.js 合并到所有其他文件之上，.sailsrc 统治一切。

问题？

与往常一样，如果您在升级过程中遇到问题，或者上面任何说明都不清楚，请告诉我们，我们会尽力澄清。

最后，对于自 8 月份发布 v0.10 以来一直为该项目做出贡献的各位：我们无法足够强调我们对您持续支持和鼓励的重视程度。有大量的问题、拉取请求、文档调整和问题，但知道我们在一起总是很有帮助 :)

谢谢。

-@mikermcneil、@sgress454 和 @particlebanana