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:
- Read
Getting started
doc.- Install
interstellar-workspace
.- Contribute to our open-source modules or develop your own.
Module contents
Classes
Module
App
Inject
annotationController
annotationProvider
annotationService
annotationWidget
annotationIntent
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.
; const mod = 'interstellar-example';mod; modcontrollers = require;moddirectives = require;modservices = require;modtemplates = require mod;
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.
;;;;; let config = ;const app = "interstellar-stellar-client" config; app;app;app;app;app; apptemplates = require;appcontrollers = require; app { $stateProvider; $stateProvider; // ...}; // Callbacks to execute in `config` block.app; // Callbacks to execute in `run` block.app; app;
Inject
annotation
Decorator class to inject dependencies to your controllers or services using AngularJS injector subsystem:
; @ { thisServer = Server; thisSessions = Sessions; }
Controller
annotation
Decorator class to annotate your controllers.
; @@ { thisServer = Server; thisSessions = Sessions; } // ...
Heads up! Annotated class must be exported as
default
.
Provider
annotation
Decorator class to annotate your providers.
; @ { thisappConfig = {}; thismodulesConfig = {}; } // ...
Heads up! Annotated class must be exported as
default
.
Service
annotation
Decorator class to annotate your services.
; @ { thisreceivers = {}; } // ...
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.
; @@ { if !Sessions console; 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 BroadcastIntentBroadcast;// Receiving BroadcastIntentBroadcast;
interstellar-core.IntentBroadcast
service
interstellar-core.IntentBroadcast
service is responsible for delivering Intent
s to correct Broadcast Receivers. It has two methods:
sendBroadcast(intent)
- to broadcast anIntent
,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 Module
s can use to define configuration values:
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
:
To overwrite this module's configuration, an app needs to add following config JSON using addAppConfig
:
get
)
Retrieving values (using 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:
You can retrieve the address for the horizon with:
let hostname = Config;
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:
Now, you can retrieve the address for the horizon with:
let hostname = Config;
getString
, getArray
, getObject
, getNumber
, getBoolean
)
Typed accessors (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.