JSPM

  • ESM via JSPM
  • ES Module Entrypoint
  • Export Map
  • Keywords
  • License
  • Repository URL
  • TypeScript Types
  • README
  • Created
  • Published
  • Downloads 10218
  • Score
    100M100P100Q118657F
  • License pemrouz.mit-license.org

Ripple Core

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

Coverage Status Build Status

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:

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