-
-
Save asciidisco/3986542 to your computer and use it in GitHub Desktop.
// PubSub impl. with require.js & backbone.js | |
// events.js | |
define(['underscore', 'backbone'], function (_, Backbone) { | |
'use strict'; | |
var events = {}; | |
_.extend(events, Backbone.Events); | |
return events; | |
}); | |
// filea.js | |
define(['events'], function (events) { | |
'use strict'; | |
events.on('my:event', function (message) { | |
console.log('Received message: ', message); | |
}); | |
}); | |
// fileb.js | |
define(['filea', 'events'], function (filea, events) { | |
'use strict'; | |
events.trigger('my:event', 'My Message'); | |
}); |
Agreed. This seems less prone to confusion. It's not that "weird behavior" you have to explain later.
Seems fine to me, I normally have something like MyAppName.vent
which I use for generic PubSub. The only issue with generic PubSub is that while it keeps your code decoupled; it's hard to document and maintain, and come up with a consistent naming convention. How do you normally name your events?
I try to avoid globals as much as possible, so I don´t have a javascript MyAppName
global in my current projects.
The application where I use this right now consists of a few modules/widgets, so i go with a naming scheme like:
shell MyWdget:Emitter:operation
For example: shell Comments:Comment:add
, when a new comment has been added to the collection of the comments widget.
Whoops, this javascript
and shell
things shouldn´t be there, copy & pasten errors...
This works extremely well.
I was in a similiar situation & wanted to have a much simpler approach.
Maybe not cleaner, but easier to understand for other devs in the team.