3 ms·

Postman - a JavaScript message bus

20 points by slace 15y ago

Postman is a JavaScript library & npm package which allows for cross-component messaging like traditional pub/ sub libraries but without the reqiurement on a message to be published after all the listeners are attached.

oinksoft 15y ago
No, it's a CoffeeScript message bus.
- slace 15y ago
  Well yes, but there is a JavaScript version in the github repository so you don't need to know what CoffeeScript is or anything
the-harsh-truth 15y ago
Congratulations. You managed to make a wrapper for arrays in god knows how many commits.
- brutally_honest 15y ago
  n00b
deleted 15y ago
[deleted]
drdaeman 15y ago
Could someone please explain me what's the point of this? I can't imagine any serious use case. It looks inefficient (uses arrays instead of linked lists/queues, so every cleanup requires full array rebuild), lacks any sort of message ordering guarantees (or notifications of lack thereof), lacks queue length limits (only time-based expiry and custom cleanup functions seeing only the value of message are provided) and so on. Moreover, I don't get the following: dropByDate = (date, msgs) -> msgs.reduce (x) -> x.created < date I believe msgs is an array (cache[name].history), but IIRC Array.reduce does not work like this, it's Array.filter that does.
- slace 15y ago
  I wrote this because the application I'm working on has dozens of small JavaScript components loaded, some of which rely on messages published by others. Some of them are invoked in-place, others are invoked as part of dom ready events so ensuring that the handlers are added before the messages are raised can't be done. Message ordering isn't important and since it's intended for asynchronous programming it shouldn't be important. As for linked lists vs arrays I'm not convinced that a linked list would be a better performer than an array for iterative access (which is a rather crucial part of the library). The reduce thing is a bug (I've chucked it on the issue register) as well as a feature request for only keeping a finite message limit.

20 points by slace 15y ago

oinksoft 15y ago

No, it's a CoffeeScript message bus.

slace 15y ago
Well yes, but there is a JavaScript version in the github repository so you don't need to know what CoffeeScript is or anything

the-harsh-truth 15y ago

Congratulations. You managed to make a wrapper for arrays in god knows how many commits.

brutally_honest 15y ago
n00b

deleted 15y ago

[deleted]

drdaeman 15y ago

Could someone please explain me what's the point of this? I can't imagine any serious use case. It looks inefficient (uses arrays instead of linked lists/queues, so every cleanup requires full array rebuild), lacks any sort of message ordering guarantees (or notifications of lack thereof), lacks queue length limits (only time-based expiry and custom cleanup functions seeing only the value of message are provided) and so on. Moreover, I don't get the following: dropByDate = (date, msgs) -> msgs.reduce (x) -> x.created < date I believe msgs is an array (cache[name].history), but IIRC Array.reduce does not work like this, it's Array.filter that does.

slace 15y ago
I wrote this because the application I'm working on has dozens of small JavaScript components loaded, some of which rely on messages published by others. Some of them are invoked in-place, others are invoked as part of dom ready events so ensuring that the handlers are added before the messages are raised can't be done. Message ordering isn't important and since it's intended for asynchronous programming it shouldn't be important. As for linked lists vs arrays I'm not convinced that a linked list would be a better performer than an array for iterative access (which is a rather crucial part of the library). The reduce thing is a bug (I've chucked it on the issue register) as well as a feature request for only keeping a finite message limit.