npm package: @lynxysscz/rin-core
Description: Small plugin centric 'framework'
Author: LynxyssCZ
Latest version: 2.0.2-0

# RinCore
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.purge`d
	- Listeners are assigned unique `id`s 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