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

interstellar-core

v0.0.4

Published

The core modules provides the lowest level functionality within the Interstellar Module System.

Downloads

30

Readme

interstellar-core

The interstellar-core module is part of the Interstellar Module System.

It provides the lowest level functionality: a core JS wrapper.

Quick start to developing in the Interstellar eco-system:

Module contents

Classes

Services

Widgets

None.

Others

Module class

Module is a wrapper around Angular.js module. Every Interstellar module is a Module object and Angular.js module. Module provides several methods to help configure a module. It also provides autoloading support for controllers, templates, services, directives and other components.

import {Module} from "interstellar-core";

export const mod = new Module('interstellar-example');
mod.use(interstellarSomeModule.name);

mod.controllers = require.context("./controllers", true);
mod.directives  = require.context("./directives", true);
mod.services    = require.context("./services", true);
mod.templates   = require.context("raw!./templates", true)

mod.define();

App class

App class extends Module class and provides helper methods for the final Interstellar application that use other modules. It provides additional functionality like ui-router. The second parameter in a constructor is a configuration JSON.

import {App, mod as interstellarCore} from "interstellar-core";
import {mod as interstellarStellarWallet} from "interstellar-stellar-wallet";
import {mod as interstellarNetwork} from "interstellar-network";
import {mod as interstellarSettings} from "interstellar-settings";
import {mod as interstellarStellarApi} from "interstellar-stellar-api";

let config = require('./config.json');
export const app = new App("interstellar-stellar-client", config);

app.use(interstellarCore.name);
app.use(interstellarStellarWallet.name);
app.use(interstellarNetwork.name);
app.use(interstellarSettings.name);
app.use(interstellarStellarApi.name);

app.templates   = require.context("raw!./templates", true);
app.controllers = require.context("./controllers",   true);

app.routes = ($stateProvider) => {
  $stateProvider.state('login', {
    url: "/login",
    templateUrl: "interstellar-stellar-client/login"
  });
  $stateProvider.state('dashboard', {
    url: "/dashboard",
    templateUrl: "interstellar-stellar-client/dashboard",
    requireSession: true
  });
  // ...
};

// Callbacks to execute in `config` block.
app.config(configureServices);

// Callbacks to execute in `run` block.
app.run(registerBroadcastReceivers);

app.bootstrap();

Inject annotation

Decorator class to inject dependencies to your controllers or services using AngularJS injector subsystem:

import {Inject} from 'interstellar-core';

@Inject("interstellar-sessions.Sessions", "interstellar-network.Server")
class ReceiveWidgetController {
  constructor(Sessions, Server) {
    this.Server = Server;
    this.Sessions = Sessions;
  }
}

Controller annotation

Decorator class to annotate your controllers.

import {Controller, Inject} from 'interstellar-core';

@Controller("HeaderController")
@Inject("interstellar-sessions.Sessions", "interstellar-network.Server")
export default class HeaderController {
  constructor(Sessions, Server) {
    this.Server = Server;
    this.Sessions = Sessions;
  }
  // ...
}

Heads up! Annotated class must be exported as default.

Provider annotation

Decorator class to annotate your providers.

import {Provider} from 'interstellar-core';

@Provider("Config")
export default class ConfigProvider {
  constructor() {
    this.appConfig = {};
    this.modulesConfig = {};
  }
  // ...
}

Heads up! Annotated class must be exported as default.

Service annotation

Decorator class to annotate your services.

import {Service} from 'interstellar-core';

@Service('IntentBroadcast')
export default class IntentBroadcastService {
  constructor() {
    this.receivers = {};
  }
  // ...
}

Heads up! Annotated class must be exported as default.

Widget annotation

Decorator class to annotate your widgets' controllers.

This annotation requires 3 arguments:

  • directive name,
  • controller name,
  • template name.
import {Widget, Inject} from 'interstellar-core';

@Widget("balance", "BalanceWidgetController", "interstellar-network-widgets/balance-widget")
@Inject("$scope", "interstellar-sessions.Sessions", "interstellar-network.AccountObservable", "interstellar-network.Server")
export default class BalanceWidgetController {
  constructor($scope, Sessions, AccountObservable, Server) {
    if (!Sessions.hasDefault()) {
      console.error('No session. This widget should be used with active session.');
      return;
    }
    // ...
  }
  // ...
}

Heads up! Annotated class must be exported as default.

Intent class

Modules in Interstellar communicate by broadcasting Intent objects using Android-inspired intent system. Modules can:

  • Broadcast Intents to trigger some events in other modules,
  • Register Broadcast Receivers to listen to Intents sent by other modules.

Every Intent has a type which must be one of standard intent types:

  • SEND_TRANSACTION - User wants to send a transaction.
  • SHOW_DASHBOARD - User wants to see a dashboard.
  • LOGOUT - User wants to logout.

Intent can also contain additional data helpful for a Broadcast Receiver. For example, SEND_TRANSACTION Intent can contain destination address.

// Sending Broadcast
IntentBroadcast.sendBroadcast(
  new Intent(
    Intent.TYPES.SEND_TRANSACTION,
    {destination: this.destination}
  )
);
// Receiving Broadcast
IntentBroadcast.registerReceiver(Intent.TYPES.SEND_TRANSACTION, intent => {
  widget.set('destinationAddress', intent.data.destination);
});

interstellar-core.IntentBroadcast service

interstellar-core.IntentBroadcast service is responsible for delivering Intents to correct Broadcast Receivers. It has two methods:

  • sendBroadcast(intent) - to broadcast an Intent,
  • registerReceiver(type, broadcastReceiver) - to register Broadcast Receiver of specific type.

interstellar-core.Config service

The Config service provides the system through which the client can retrieve configuration flags. It provides a get(configName) to which clients can retrieve values.

Conceptually, an application's configuration presents itself as a simple nested json object.

Defining configuration values

interstellar-core.Config provider has 2 methods that App and Modules can use to define configuration values:

  • addAppConfig(config) - used by App
  • addModuleConfig(moduleName, config) - used by Modules

All config values added by modules are treated as default values that can be overwritten by the App config. For example, let's say interstellar-network module adds following config JSON using addModuleConfig:

{
  "horizon": {
    "secure": true,
    "hostname": "horizon-testnet.stellar.org",
    "port": 443
  }
}

To overwrite this module's configuration, an app needs to add following config JSON using addAppConfig:

{
  "modules": {
    "interstellar-network": {
      "horizon": {
        "secure": false,
        "hostname": "horizon.example.com",
        "port": 80
      }
    }
  }
}

Retrieving values (using get)

Once you have an instance of the config service (using normal angular DI mechanisms), you may access any previously loaded configuration using a "dot separated" accessor string. For example, say the App configuration data is the json object below:

{
  "horizon": {
    "secure": true,
    "hostname": "horizon-testnet.stellar.org",
    "port": 443
  }
}

You can retrieve the address for the horizon with:

let hostname = Config.get("horizon.hostname");

Getting configuration values in Module is a little different. During configuration phase all modules' configurations are appended to modules object in the main config JSON. For example, let's say interstellar-network module adds following configuration:

{
  "horizon": {
    "secure": true,
    "hostname": "horizon-testnet.stellar.org",
    "port": 443
  }
}

Now, you can retrieve the address for the horizon with:

let hostname = Config.get("modules.interstellar-network.horizon.hostname");

Typed accessors (getString, getArray, getObject, getNumber, getBoolean)

In the spirit of failing fast, consumers of the config service can apply type restrictions to config variables, such that an exception will be thrown at the point of retrieval if the result is of the wrong type. For example, given a config object of {"foo": "bar"}, executing the statement Config.getNumber("foo") will throw an exception because the result ("bar") is a string.