Skip to content
Service Objects for Marionette
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
dist
src
test
.editorconfig
.gitignore
.jscsrc
.jshintrc
.travis.yml
CHANGELOG.md
LICENSE
README.md
bower.json
gulpfile.js
package.json
yarn.lock

README.md

Marionette Service

Travis build status Code Climate Test Coverage

CHANGE FOR 1.0.0

With the 1.0.0 release, this library has been updated to be based off of Backbone.Model rather than Marionette to minimize the dependencies, and allow for the user of service objects without pulling in all of Marionette.

This is a library to add "Service Objects" to Marionette 2.1+. Service Objects are an extension of Backbone.Model that allows declarative interaction with Backbone.Radio messages. Service Objects can respond to both of Radio's message types; Events and Requests. The syntax is similar to the events syntax from Backbone Views, and looks like this:

radioEvents: {
  'app start': 'onAppStart',
  'books finish': 'onBooksFinish',
},


radioRequests: {
  'resources bar': 'getBar',
},

where each hash value is in the form 'channel eventName' : 'handler'. So

radioRequests: {
  'app doFoo': 'executeFoo',
},

means that the Service will listen for the doFoo command on the app channel, and run the 'executeFoo' method. When using Radio Requests with Objects, the same rules and restrictions that normal Radio use implies also apply here: a single handler can be associated with a request, either through manual use of the reply functions, or through the Service API.

Installation via Package Manager

npm

npm install marionette-service

bower

bower install marionette-service

Questions

Wouldn't this be a good fit for Marionette Core?

This feature will be included as part of Marionette.Object in Marionette v3.0.0. This library is intended as a way to use the feature in 2.1+ apps without having to wait for 3.0.

Why add a separate Service class instead of shimming the future behavior on Mn.Object?

Marionette 3.0 isn't finalized yet. APIs may change in the meantime. I don't want updating to 3.0 to break any existing service code. If the API does change I will try to track it with this library, but will do so in a semver fashion. Assuming that the API does remain stable, upgrading to the core code will consist of renaming all Service objects to Object and removing this dependency.

You can’t perform that action at this time.