Burns is a lightweight (no dependencies!) Node.js module for managing application events elegantly. Define your events and handlers in one place and dispatch them when you need to.
Inspired by Laravel's events and broadcasting systems.
- Easy visibility of all application events
- Default handler to catch generic events
- Attaching event handlers at multiple places
- Asynchronous handling of events
- Inbuilt event broadcasting
npm install burns
const burns = require('burns');
Define an event handler:
// handlers/order.js
function sendOrderShippedEmail(data)
{
mailer.sendEmail(`Hi ${data.userName}, Your order ${data.orderId} has been shipped`);
}
Register the event and attach the handler:
let { sendOrderShippedEmail } = require('./handlers/order');
burns.registerEvents({
orderShipped: sendOrderShippedEmail
});
Dispatch the event when you're ready! ๐
burns.dispatch('orderShipped', {
orderId: order.id,
userName: user.name
});
Register events by calling registerEvents
with a single object. The names of your events should be the keys of this object and their handlers the values:
burns.registerEvents({
newPurchase: sendInvoice,
orderShipped: notifyUser
});
You can also attach multiple handlers to a single event:
burns.registerEvents({
userSignUp: [
userListener.sendEmail,
userListener.congratulateReferrer
]
})
Burns allows you to register events at multiple locations. This means that for a large application, you can have each application component define its own events and handlers by calling registerEvents
wherever it needs to.
A handler is a function that responds to an event. A handler takes a single parameter, the event payload which you pass when dispatching the event:
function sendInvoice(data)
{
let invoice = createInvoice(data.order, data.user);
mailer.sendEmail('Here is your order invoice', invoice);
}
burns.registerEvents({
newPurchase: sendInvoice,
});
// this will call sendInvoice with data = {}
burns.dispatch('newPurchase');
// this will call sendInvoice with data containing order and user
burns.dispatch('newPurchase', {
order: getOrder(),
user: findUser()
});
Suppose you're running a subscription service (like Netflix) where you bill users every month. Your app can fire a newBillingPeriod
event and perform multiple actions when this event is fired: charge the customer's card, extend their subscription, send them a invoice. Burns allows you to register multiple handlers for the event, and will call them in the order in which they were registered:
burns.registerEvents({
newBillingPeriod: [
chargeCustomerCard,
extendCustomerSubscription,
sendCustomerInvoice,
]
})
If the process of charging the customer's card fails, you probably wouldn't want to go through with the other actions. In such a situation, you can prevent the subsequent handlers from being called by returning false
from the current handler:
function chargeCustomerCard(customer) {
if (!PaymentProcessor.chargeCard(customer)) {
// bonus: dispatch a 'chargeCardFailed` event. Cool, huh?
burns.dispatch('chargeCardFailed', customer);
return false;
}
}
You may specify a defaultHandler
. Burns will pass a dispatched event to this handler if no handlers are registered for it:
function handleEverything (data) {}
burns.configure({
defaultHandler: handleEverything
});
// this will call handleEverything
burns.dispatch('unregisteredEvent', somePayload);
To dispatch an event, call dispatch
with the name of the event:
burns.dispatch('postLiked');
You may also pass in a payload containing data to be transmitted with the event:
burns.dispatch('postLiked', {
postId: 69,
likedBy: 42,
});
This object will be passed as an argument to the handler.
Supposing you have an orderStatusUpdated
event that is fired when the status of an order is updated, and you wish to update the order status on your frontend in realtime. Burns handles this for you via event broadcasting.
You'll need to specify a broadcaster
. For now, broadcasting is only supported to the console log (broadcaster: 'log') and Pusher (broadcaster: 'pusher'). The default broadcaster is log
, which will log all broadcasts to the Node console. (You can disable broadcasting by setting broadcaster: null
.)
If you're broadcasting with Pusher, pass in your credentials as a pusher
object:
burns.configure({
broadcaster: 'pusher',
pusher: {
appId: 'APP_ID',
key: 'APP_KEY',
secret: 'SECRET_KEY',
cluster: 'CLUSTER',
}
})
โ To use the
pusher
broadcaster, you need to install the Pusher Node.js SDK:npm install pusher
Then register the orderStatusUpdated
using the "advanced" configuration format:
burns.registerEvents({
orderStatusUpdated: {
handlers: [
notifyUser
],
broadcastOn: 'orderStatusUpdates' // or an array of channels
}
});
The broadcastOn
key specifies the name of the channel on which the event will be broadcast. It can be a string or a function that takes in the event payload and returns a channel name.
Now when you call
burns.dispatch('orderStatusUpdated', order);
Burns will automatically publish a message on the channel orderStatusUpdates
with the order
object as the payload. All that's left is for you to listen for this event on the frontend.
If you'd like to exclude the client that triggered the event from receiving the broadcast, you can pass in an object as the third parameter to dispatch()
. The 'exclude' key should contain the socket ID of the client to exclude:
burns.dispatch('orderStatusUpdated', order, { exclude: socketId });
You can also have conditional broadcasting by using the broadcastIf
property.
burns.registerEvents({
orderStatusUpdated: {
handlers: [
notifyUser
],
broadcastOn: 'orderStatusUpdates',
broadcastIf: process.env.NODE_ENV === 'production'
}
});
You may specify a function that takes the event payload and should return true or false:
({
broadcastIf: (data) => data.user.notifications.enabled === true,
// your function can return a promise too. Burns will await the result
// broadcastIf: (data) => data.user.getSettings()
// .then(settings => settings.notifications.enabled === true),
})
`
Yes, and that's a great thing for handling events at lower levels in your code base (for instance, on open
of a file, on data
of a stream). When dealing with events at a higher level (such as a new user signing up), Burns is perfect for helping you keep your code clean and organized.
Unlike Node.js' inbuilt events system, Burns calls your event handlers asynchronously in the order in which they were registered. This means that the functions are queued behind whatever I/O event callbacks that are already in the event queue, thus enabling you to send a response to your user immediately, while your event gets handled in the background.
This also means that if you dispatch one event from a handler for another event, all of the original event's handlers will be executed first, before moving on to those for the newly-dispatched event.
Star and share, and give me a shout out on Twitter
If you have an bugfix, idea or feature you'd like to implement, you're welcome to send in a PR!
(Requires Node v8 or above)
- Clone the repo
git clone https://github.com/shalvah/burns.git
- Create a branch for your fix/feature:
git checkout -b my-patch
-
Write your code. Add tests too, if you know how. If you're not sure how, just send in the PR anyway.
-
Make sure all tests are passing
npm run test