4 ms·
What problem does this solve? Can't you just simply declare the "loosely coupled" methods as functions and call them wherever needed in vanilla javascript? Perh
by Mahn 12y ago
What problem does this solve? Can't you just simply declare the "loosely coupled" methods as functions and call them wherever needed in vanilla javascript? Perhaps I'm missing something but judging by the examples, and assuming the messages are local to a particular process, I don't see why would you do this:
msngr.register({ topic: "Save", category: "Profile", dataType: "application/json" }, function (payload) {
console.log("Save profile information here");
});
msngr.emit({ topic: "Save", category: "Profile", dataType: "application/json" }, {
name: "Kris",
country: "United States"
});
Rather than:
function saveProfile(payload) {
console.log("Save profile information here");
}
saveProfile({
name: "Kris",
country: "United States"
});
- michael_fine 12y agoThe examples don't illustrate this very well, but the benefit of message passing is flexibility/decentralization of events. To use your example, if when you saved the profile you wanted to also pass it to an internal analytics database, makes more organizational sense to have that database just register a listener for a save profile event, rather than having to add a very auxiliary step within the saveProfile function. This gets more and more helpful the more listeners you have, and while I haven't looked at this library in depth, can also be a very natural way of writing async code.
- BinaryIdiot 12y agoI wish I had some examples in my repo (still considering this more of a beta so I'll get to it eventually) but the big thing for me is the separation with descriptive meta data. The idea behind this is so you can create message receivers that can respond to a variety of items without even knowing the origin. Much like Android intents where intents can come from internally or externally these messages can be handled the same way (hence my primary use case is using them with web components; I can make a web component publish specific messages and have my business logic handle them without ever touching anything in the UI layer). I started working on an experiment where I wrote two controllers that handled the UI with msngr.bind(), one for a web browser and one for a native application using node-qt (which is basically a dead project now and one of the reasons I never finished my experiment but I digress). The business logic never had to chance at all but the controllers could be swapped. It's not hugely different than your example but I like the separation and descriptiveness it gives me. I also have plans to eventually revisit old code I have written where messages can cross web browser windows and the client-server boundary but not sure when I'll get to that. Hope that helps!
- HillRat 12y agoMy homegrown front-end library has a similar pub-sub mechanism (probably a bit more heavyweight than the OP's implementation) and uses it extensively for UI coupling, data-binding and asynchronous call management. It's certainly a lot more ceremony than passing functions around, but it also makes it possible to determine who's generating and dispatching on events, simplifies debugging, and allows you to drop in functionality by simply wiring an object up to listen for the appropriate messages (particularly nice for logging). It's overkill for probably 80% of the pages you write, but really nice to have in the toolbox for the more complex problems.
- muraiki 12y agoI'm using postal.js for pubsub in a webapp where I have components that I'd like to reuse but are sometimes used in varying contexts, such that zero, one, or more other components will be interested in that component's actions. This way, any given component doesn't need to know how many / which other components are interested in its events -- it can simply publish them.