Most users of the Sails framework will never need to access more than a few basic methods of the sails
application object. However, if you have an advanced use case or are considering contributing to Sails, you may need to delve into some of these lesser-used methods or reference the loading order of Sails core.
sails
globalWe recommended using the sails
global with Sails.
However, the auto-globalization of sails
can be disabled. Disabling the sails
global might be a good idea for use cases where multiple Sails app instances need to exist at once, or where globals are not an option.
If the sails
global is disabled, then you'll need another way to reference the application instance. Luckily, this is possible from almost anywhere in your app:
fn
of an action (this.sails
)fn
of a helper (this.sails
).req._sails
)A dictionary of all loaded Sails hooks, indexed by their identity. Use sails.hooks
to access properties and methods of hooks you've installed to extend Sails—for example, by calling sails.hooks.email.send()
. You can also use this dictionary to access the Sails core hooks, for advanced usage.
By default, a hook's identity is the lowercased version of its folder name, with any sails-hook-
prefix removed. For example, the default identity for a hook loaded from node_modules/sails-hook-email
would be email
, and the hook would be accessible via sails.hooks.email
. An installed hook's identity can be changed via the installedHooks
config property.
See the hooks concept documentation for more information about hooks.
sails.io
The API exposed by the sails.sockets.*
methods is flexible enough out of the box to cover the requirements of most applications, and using them will future-proof your app against possible changes in the underlying implementation. However, if you are working on bringing some legacy code from a vanilla Socket.io app into your Sails app, it can be useful to talk to Socket.io directly. To accomplish this, Sails provides raw access to the underlying socket.io server instance (io
) as sails.io
. See the Socket.io docs for more information. If you decide to use Socket.io directly, please proceed with care.
Sails bundles
socket.io
as a dependency of sails-hook-sockets, a core hook.
An application instance automatically created the first time you require('sails')
.
This is what is happening in the generated app.js
file:
var sails = require('sails');
Note that any subsequent calls to require('sails')
return the same app instance. (This is why you might sometimes hear the Sails app instance referred to as a "singleton".)
If you are implementing something unconventional (e.g. writing tests for Sails core)
where you need to create more than one Sails application instance in a process, you should not use
the instance returned by require('sails')
, as this can cause unexpected behavior. Instead, you should
obtain application instances by using the Sails constructor:
var Sails = require('sails').constructor;
var sails0 = new Sails();
var sails1 = new Sails();
var sails2 = new Sails();
Each app instance (sails0
, sails1
, sails2
) can be loaded/lifted separately,
using different configuration.
For more on using Sails programatically, see the conceptual overview on programmatic usage in Sails.