npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@overlook/plugin

v0.4.1

Published

Overlook framework Plugin class

Downloads

19

Readme

NPM version Build Status Dependency Status Dev dependency Status Greenkeeper badge Coverage Status

Overlook framework Plugin class

Part of the Overlook framework.

Introduction

Overlook framework Plugin class. Plugins should be created with this class.

Overlook is intended to be extremely modular and flexible.

The base Route class has very little functionality, and most functionality is intended to be added using plugins.

Plugins apply per route, not at application level.

One route, or subtree of routes, can have one behavior, another subtree can have another. So, for example, one part of the app can use React, another part can server-render pages from EJS templates.

This architecture allows:

  1. "Snap in" plugins providing common functionality, making building apps fast
  2. Granular control over every route's individual behavior

Usage

Creating a plugin

A plugin is created from a function which receives a Route class and should return a subclass of it.

const Plugin = require('@overlook/plugin'),
  makeSymbols = require('@overlook/util-make-symbols'),
  { INIT_PROPS, INIT_ROUTE } = require('@overlook/route');

const { TYPE, GREETING } = makeSymbols(
  [ 'TYPE', 'GREETING' ]
);

const mammalPlugin = new Plugin( Route => (
  class extends Route {
    [INIT_PROPS]( props ) {
      super[INIT_PROPS]( props );
      this[TYPE] = undefined;
    }

    [INIT_ROUTE]( app ) {
      super[INIT_ROUTE]( app );
      if (this[TYPE] === undefined) this[TYPE] = 'mammal';
    }

    [GREETING]() {
      return `Hello, I am a ${this[TYPE]}.`;
    }
  }
) );

mammalPlugin.TYPE = TYPE;
mammalPlugin.GREETING = GREETING;

New methods and properties should have Symbol keys, not strings. If properties are intended to be accessed by other plugins, or methods intended to be available for extending, the Symbol should be exported as a property of the Plugin object.

The plugin can than be used create a subclass of a Route class, using .extend():

const Route = require('@overlook/route');

const MammalRoute = Route.extend( mammalPlugin );

That subclass can now be used to create a route which includes the plugin's functionality:

const route = new MammalRoute();

route[ mammalPlugin.GREETING ]()
// => 'Hello, I am a mammal.'

Removing Symbols boilerplate

It's typical for a plugin to define Symbols.

To reduce boilerplate code, you can create Symbols within the Plugin constructor. The plugin is passed to extend() as 2nd arg, so you can access the symbols from there.

This example is equivalent to the first:

const Plugin = require('@overlook/plugin'),
  { INIT_PROPS, INIT_ROUTE } = require('@overlook/route');

const mammalPlugin = new Plugin(
  { symbols: [ 'TYPE', 'GREETING' ] },
  ( Route, { TYPE, GREETING } ) => class extends Route {
    [INIT_PROPS]( props ) {
      super[INIT_PROPS]( props );
      this[TYPE] = undefined;
    }

    [INIT_ROUTE]( app ) {
      super[INIT_ROUTE]( app );
      if (this[TYPE] === undefined) this[TYPE] = 'mammal';
    }

    [GREETING]() {
      return `Hello, I am a ${this[TYPE]}.`;
    }
  }
);

The symbols are also automatically set as properties of mammalPlugin.

Publishing a plugin to NPM

new Plugin() has a few more options which should be used when publishing a plugin to NPM.

  1. You should provide the name and version of the module.
  2. Symbols must be created using either @overlook/util-make-symbols or the Plugin constructor.
// Published as `@me/monkey`
// version 1.0.0
const Plugin = require('@overlook/plugin');

const monkeyPlugin = new Plugin(
  {
    name: '@me/monkey',
    version: '1.0.0',
    symbols: [ 'GREETING' ]
  },
  Route => class extends Route { /* ... */ }
);

module.exports = monkeyPlugin;

The options object has the same properties as package.json so, to avoid having to update the version property every time you publish a new version of the module, you can pass that instead.

const pkg = require('./package.json');

const monkeyPlugin = new Plugin(
  pkg,
  { symbols: [ 'GREETING' ] },
  Route => class extends Route { /* ... */ }
);

Longer example including using symbols

const Plugin = require('@overlook/plugin');
const pkg = require('./package.json');

const monkeyPlugin = new Plugin(
  pkg,
  { symbols: [ 'GREETING' ] },
  ( Route, { GREETING } ) => class extends Route {
    [GREETING]() {
      return 'Hello, I am a monkey.';
    }
  }
);

Composing plugins

Plugins can extend other plugins.

Let's say we have various routes which need a "greeting" method. This functionality can be split off into its own plugin.

const Plugin = require('@overlook/plugin'),
  { INIT_PROPS, INIT_ROUTE } = require('@overlook/route');

const greetingPlugin = new Plugin(
  { symbols: [ 'TYPE', 'GET_TYPE', 'GREETING' ] },
  ( Route, { TYPE, GET_TYPE, GREETING } ) => class extends Route {
    [INIT_PROPS]( props ) {
      super[INIT_PROPS]( props );
      this[TYPE] = undefined;
    }

    [INIT_ROUTE]( app ) {
      super[INIT_ROUTE]( app );
      this[TYPE] = this[GET_TYPE]();
    }

    [GET_TYPE]() {
      return 'mystery';
    }

    [GREETING]() {
      return `Hello, I am a ${this[TYPE]}.`;
    }
  }
} );

Now other plugins can extend off that:

const monkeyPlugin = new Plugin( {
  extends: [ greetingPlugin ],
  extend: ( Route, { GET_TYPE } ) => class extends Route {
    [GET_TYPE]() {
      return 'monkey';
    }
  }
} );

const zebraPlugin = new Plugin( {
  extends: [ greetingPlugin ],
  extend: ( Route, { GET_TYPE } ) => class extends Route {
    [GET_TYPE]() {
      return 'zebra';
    }
  }
} );

const MonkeyRoute = Route.extend( monkeyPlugin );
const monkey = new MonkeyRoute();
monkey[GREETNG]()
// => 'Hello, I am a monkey.'

const ZebraRoute = Route.extend( zebraPlugin );
const zebra = new ZebraRoute();
zebra[GREETNG]()
// => 'Hello, I am a zebra.'

Plugins automatically inherit the Symbols (and any other properties) of the plugins they extend.

Symbols a plugin defines must therefore not have name clashes with plugins they extend. An error will be thrown if this is the case.

zebraPlugin.GREETING === greetingPlugin.GREETING // => true

isPlugin() static method

isPlugin() returns true if input is a Plugin.

const Plugin = require('@overlook/plugin');
const plugin = new Plugin( () => {} );

Plugin.isPlugin( plugin ) // => true

Versioning

This module follows semver. Breaking changes will only be made in major version updates.

All active NodeJS release lines are supported (v10+ at time of writing). After a release line of NodeJS reaches end of life according to Node's LTS schedule, support for that version of Node may be dropped at any time, and this will not be considered a breaking change. Dropping support for a Node version will be made in a minor version update (e.g. 1.2.0 to 1.3.0). If you are using a Node version which is approaching end of life, pin your dependency of this module to patch updates only using tilde (~) e.g. ~1.2.3 to avoid breakages.

Tests

Use npm test to run the tests. Use npm run cover to check coverage.

Changelog

See changelog.md

Issues

If you discover a bug, please raise an issue on Github. https://github.com/overlookjs/plugin/issues

Contribution

Pull requests are very welcome. Please:

  • ensure all tests pass before submitting PR
  • add tests for new features
  • document new functionality/API additions in README
  • do not add an entry to Changelog (Changelog is created when cutting releases)