workhorsejs
v1.0.1
Published
web workers wrapped in event emitters
Downloads
4
Maintainers
Readme
workhorse.js
web workers on crack! (should have called it whitney)
The goal behind workhorse is to simplify messaging between a worker and client interface. It also adopts some concepts from the ServiceWorker spec.
Events
on(event, handler)
var worker = new Workhorse('thing.js');
worker.on('wat', function (e) {
console.log(e.data);
});
off(event, [handler])
// remove all the "wats"
worker.off('wat');
emit(event, [data])
worker.on('wat', function (e) {
console.log(e.data.message);
});
worker.emit('wat', { message : 'hi!' }); // => "hi!"
once(event, handler)
worker.once('wat', function () {
console.log('hi!');
});
worker.emit('wat'); // => "hi!"
worker.emit('wat'); // nothin'
post(event, data)
worker.post('wat', { message: 'hi' });
What are the differences between emit
and post
?
post
sends a message across the wire, this would be the equivilant ofpostMessage
.emit
triggers any and all event handlers associated with an event. This does not send a message across the wire.
Responding to events
By default web workers offer a very simple messaging system which can get messy quick when a worker potentially has multiple responsibilities.
Rather than wiring up multiple events for a game of ping pong, we should be able to easily respond to an event via the event
object.
worker.on('wat', function (event) {
event.respondWith({
message: 'Hello!'
});
});
Recieving responses
So just like the issue of responding to events, how does a client recieve that response without wiring up an additional event? This seems like a fitting place to use promises.
worker.post('wat', { wat: 'wat' })
.then(function (response) {
console.log(response.message); // => "Hello!"
});
Considerations
Things to consider while developing
- There are multiple types of workers (Worker, SharedWorker, etc.)
- It's possible to spin up a worker via
port
property (worker.port
) - Nothing could probably ever take Whitney in a fist fight