Skip to content

Instantly share code, notes, and snippets.

@mikermcneil
Last active October 19, 2020 08:42
Show Gist options
  • Save mikermcneil/5746660 to your computer and use it in GitHub Desktop.
Save mikermcneil/5746660 to your computer and use it in GitHub Desktop.
Sails.js v0.9 plugins proposal

A Modest Proposal: Hooks

Sails.js v0.9: Release Cantidate for 1.0

Philosophy

  • The question of what "belongs" in a framework is complex, and depends on your use case. A better question is "what are the defaults?" By pulling all of the current features of Sails into plugins, and then including them by default, we provide full customizability (the possibility of disabling just about everything) without sacrificing all the conveniences Sails developers are used to.
  • Plugins make it easier to contribute, and make modifying the core a much less scary proposition.
  • Node.js is quite minimalist, and super awesome. Let's take a leaf out of Ryan/Isaac's book!
  • Community plugins are fantastic, but to ensure quality, plugins will only be listed on the Sails website/repo when they've met some basic quality assurance testing.

How It Works

When an app starts up, after the core components load, the initialize method is triggered for each of the configured plugins. Plugins can tap into events emitted from Sails, and hook into other parts of the app bootstrap process that way.

Plugins also have access to the Sails CLI, if developers choose to configure their installation to use them. The cli:new, cli:generate, and cli:build events are automatic, plus you can add your own command-line hooks.

Best Practices

If a plugin provides configuration options, it should hook into the Sails CLI to generate them for new projects on sails new. It should also declare the options in its plugin.json file.

If a plugin adds routes, it should declare them explicitly in its plugin.json file.

If a plugin adds middleware, it should declare them explicitly in its plugin.json file.

If a plugin expects a special directory/files to exist at the app level, it should register that with the Sails module loader so the path is fully configurable for end users. The plugin should also create the directory on sails new.

More to come!

@JemiloII
Copy link

JemiloII commented Aug 4, 2014

So this was something, but found my answers via sails console. It's loaded with information

@kowal2205
Copy link

I looked at the code which is definitly well organised in 0.10 version, vert gold job
Just few question about hooks and module loader:
Hooks' objets are only used for boostraping, use only sails défaut folders, do notre expose any method (like a add(data|file|directoires) méthod to dynamicly add new controllers, modèls ...). It is on thé roadmap or do you think that such functionalities must je provided by users hooks even for standards objects ?
What is the idea behind the centralisation of 'loadhookobjects' méthodes in module loader ? They should be private fonctions in hooks definition because only used during the hooks' objectb init. Is it the beginning of a global serviceManager ?

@tjwebb
Copy link

tjwebb commented Sep 1, 2014

where are plugin docs/examples?

@leejt489
Copy link

@Vadorequest
Copy link

I believe examples/doc/tuto would be great there, but the one provided by @leejt489 helps a bit indeed.
And @mikermcneil yes, I think you should create a default folder in api/hooks with some README.md.

@uncletammy is working on some docs on the subject

@mikermcneil
Copy link
Author

@listepo
Copy link

listepo commented Oct 9, 2015

I like how the components ember.js. It is important to be able to customize. I think it makes sense to write in es6 with babel.

for example:

/api/plugins/waterline-plugin/collection.js

import CollectionPlugin from 'waterline-plugin/collection';

class Collection extends CollectionPlugin {
    loadDocument (doc) {
        ...
        //Code here
        ...
        return super(doc);
    }
}

export default Collection;

/api/plugins/waterline-plugin/waterline.js

import WaterlinePlugin from 'waterline-plugin';
import Collection from './collection';

class Waterline extends WaterlinePlugin {
    constructor (...arguments) {
        this.Collection = Collection;
        return super(...arguments);
    }
    afterLoad () {
        ...
        //Code here
        ...
    }
}

export default Waterline;

@mikermcneil, what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment