Comparing version 1.4.0 to 1.4.1
@@ -34,3 +34,3 @@ # Core Events | ||
If you want to add/trigger events to monkeypatch your Sails core, it's best to do this by authoring a hook. More information will show up as we learn more about best practices around that process, but one thing we've definitely learned is that you're better off namespacing your events and firing them on a single object (`sails`), then emitting and listening on different objects. Why? Sometimes objects get deleted or copied, and this can make a big mess. | ||
If you want to add/trigger events to monkeypatch your Sails core, it's best to do this by authoring a hook. More information will show up as we learn more about best practices around that process, but one thing we've definitely learned is that you're better off namespacing your events and firing them on a single object (`sails`), than emitting and listening on different objects. Why? Sometimes objects get deleted or copied, and this can make a big mess. | ||
@@ -37,0 +37,0 @@ If you need a special event in your hook, you *will* want to namespace it. For instance, if I'm adding a hook called `enforceRestfulSesssions` that limits the actions that can be added to controllers to encourage code consistency, I might have a `hook:enforceRestfulSesssions:checked` event that fires when all of the controllers have been checked. This is so that other hooks that know about `enforceRestfulSesssions` can wait until it has finished its check before proceeding (whether it's just me, or other people on my team, or if I release my hook and it gets popular, other people in the Sails community). |
{ | ||
"name": "sails", | ||
"author": "Mike McNeil <@mikermcneil>", | ||
"version": "1.4.0", | ||
"version": "1.4.1", | ||
"description": "API-driven framework for building realtime apps, using MVC conventions (based on Express and Socket.io)", | ||
@@ -61,3 +61,3 @@ "license": "MIT", | ||
"rttc": "^10.0.0-0", | ||
"sails-generate": "^2.0.0", | ||
"sails-generate": "^2.0.3", | ||
"sails-stringfile": "^0.3.3", | ||
@@ -64,0 +64,0 @@ "semver": "4.3.6", |
@@ -24,7 +24,2 @@ # [![Sails.js logo](http://balderdashy.github.io/sails/images/logo.png "Sails.js")](http://sailsjs.com) | ||
> ##### Upgrading from an earlier version of Sails? | ||
> | ||
> Available as of Node >=v7.9 and Sails >=v1.0, ES8's async/await enables dramatic improvements to the way developers build Node.js / Sails apps. It allows server-side JavaScript code to be written with the `await` keyword, instead of lower-level (and more fragile) flow control mechanisms like nested callbacks and promise chains. It lets developers breathe easier by removing the burden of painstaking, manual error handling after every database query. And best of all, it means **the end of "callback hell"**: the most common source of bugs and stability issues in real world Node.js / Sails applications. | ||
> | ||
> If ES8 isn't for you, don't worry-- Node callbacks and promise chaining are still fully supported. But for most teams, the transition to `await` results in sizable gains in productivity, with fewer lines of code. | ||
> | ||
> Upgrade guides for all major releases since 2013 are available on the Sails website under [**Upgrading**](http://sailsjs.com/upgrading). | ||
@@ -31,0 +26,0 @@ |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
3253776
726
130
Updatedsails-generate@^2.0.3