Rinko

Small container based app toolkit.

Components

These are the main components that Rincore is composed of.

Relay

Relay is Promise based pub/sub implementation. It aims to execute listeners asynchronously and returns resolutions of each listener callback.

Bus

Is Relay consumer and introduces some sugar atop of it, namely:

• Listeners management
  • Multiple instances of Bus can safely share one Relay using Bus.tap
  • Instance holds references to it's listeners and removes them from shared Relay when Bus.purged
  • Listeners are assigned unique ids and can be removedusing that id (usefull for arrow functions and such)
• Changes raw message into a structure:
  • origin - identifier of the bus that emited this message
  • channel - channel into which this message was emited (can be useful for multi-channel listeners)
  • message - the original message

Bus forms flat, not tree based structure. Purging a Bus does not purge other instances created by it's Bus.tap. This was removed due to it's complexity and the fact, that this code would be redundant with tree structure managed by Shelf.

Registry

Registry is key/value storage. It uses concept of paths to simulate trie based storage while using a hash map. Multiple Registry instances created by calling Registry.child({name}) share the same storage and try to naively track their paths to clear the on Registry.purge.

Shelf

The main building block of RinCore based application. Shelf manages relations and rough lifecycle of functional blocks while aiming to separate their APIs. It provides a way of structuring code into completely independent modules that have clean and sandboxed environment, in which contextual polution can only go down the structure.

Shelf does this using two basic concepts

• Shelf - A box for your code to do it's thing. Exposes a basic API for adding child Shelves directly dependent on this one. Provides rough lifecycle:
  • Construction - New Shelf is constructed and estabilishes a link with it's parent
  • Init phase - First asynchronous part of the lifecycle. shelved code is allowed to register it's children from now on and perform any needed asynchronous initialization steps.
  • Start phase - The app is being started. Good point to register your timers and other listeners.
  • Stop phase - this phase is optional and only happens if the shelf was succesfully started. Here you should clean up your listenrs and open connections, so app can terminate normally.
• Extension - A way to extend the basic Shelf API and add functionality (or state) that bleeds down the tree if desired.
  • Extensions have their own lifecycle
  • They can interfere with Shelf lifecycle using asynchronous hooks
  • State is linked to specific Shelf instances
  • This code is provided with parent shelf API at the init stage of it's lifecycle

Libraries

Libraries supporting the components.

Promising

Promising is trying to fill the gap between async.js and pure Promise. It leverages iterators and executes a promise bassed callback on a data collections.

Main aims are

• Concurency of 1 (main beef with Promise.all)
• Executing callback in the right order (Bluebird.map failed me there)

Main Problems

• Could use some optizations

API

Shelf

Basic lifecycle:

• constructor(shelfRecipe, parent)
• init
• start
• stop

Get/Set

• getName
• getPath
• getApi
• addToApi

Hierarchy management

• addShelves(shelfRecipes)
• addShelf(shelfRecipe)
• removeShelf(shelfName)
• purge

Extensions

• extend(extension, options)

Tests

TO-DOs