Package Exports
- rijs.core
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (rijs.core) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Ripple | Core
A simple extensible in-memory data structure of resources.
var ripple = core()
ripple(name, body) // setter
ripple(name) // getter
You can also use the method-chained API:
ripple
.resource(name, body)
.resource(name, body)
...
The resources it registers are accesible under ripple.resources
.
A canonical resource is an object with the following shape and three properties:
{ name: 'foo'
, body: 'bar'
, headers: { 'content-type': 'text/plain' }
}
That is, it can be uniquely identified (name
), the resource itself (body
) and some arbitrary metadata (headers
). Core only deals with the content-type
header, however other modules may add and interpret their own per-resource metadata.
Core only comes with one type (text/plain
) out of the box, so will fail to register anything other than a string. This is to make it very extensible and future-proof, such that you could for example create other exotic types like application/jsx
, text/jade
or data/immutable
.
Note that you do not have to register a canonical resource, you will most likely use shortcuts in your application code (see API for more).
ripple('foo', 'bar')
// will result in ripple.resources ===
{
foo: { name: 'foo'
, body: 'bar'
, headers: { 'content-type': 'text/plain }
}
}
Resource Interpretation
When an content-type header is not explicitly given, core will loop through it's registered types and see if any of them understand this particular resource (by passing { name, body, headers }
to each type check
function). If any of them do:
- The
content-type
header will be set - The type
parse
function will be run on the resource - The resource will be stored internally
- A change event will be emitted
You'll need to extend ripple.types
to tell it how to interpret other resources. Each type object should have the following:
{ header: 'the content type you are registering'
, check: function // necessary
, parse: function // optional
}
The parse
function is a chance to initialise the resource, set default headers, etc. Some examples:
application/data
- proxies change events so you can do per-resource change listenersripple('data').on('change, fn)
application/javascript
- turns a function as a string into a real function (useful since streamed over WS).
Other modules can also extend existing parse functions. For example, sync
extends every type parse function to add the ability to define server/client transformation functions.
See other existing vanilla types for more examples: Data, Versioned Data, Functions, HTML, CSS.
Event
The core instance is emitterified. Whenever a resource is registered, a change event will be emitted.
ripple.on('change', doSomething)
API
ripple('name') // - returns the resource body if it exists
ripple('name', body) // - creates & returns resource, with specified name and body
ripple('name', body, headers }) // - creates & returns resource, with specified name, body and headers
ripple({ name, body, headers }) // - creates & returns resource, with specified name, body and headers
ripple([ ... ]) // - calls ripple on each item - registers an array of resources
ripple.resources // - returns raw resources
ripple.resource // - alias for ripple, returns ripple instead of resource for method chaining
ripple.register // - alias for ripple
ripple.on // - event listener for changes - all resources