D4mations.com

Modular Javascript #4 – PubSub Javascript Design Pattern



Last video, we covered the revealing module pattern – where we expose an API allowing modules to talk to each other. This works well for smaller amounts of modules, but can have issues when many modules need to talk to each other.

Here’s the pubsub code I’m using in this example: https://gist.github.com/learncodeacademy/777349747d8382bfb722

In this video, we’ll cover the pubsub design pattern (publish/subscribe), which allows us to decouple our modules. Once integrated with our pubsub module, they can emit events and not have to worry about which modules depend on them. Modules can subscribe to events and be notified when any module publishes.

Original source

d4mer

, , , , , , ,

46 responses to “Modular Javascript #4 – PubSub Javascript Design Pattern”

  10. I don't understand why the functions are pushed into a list of event handlers within the pubsub module. Aren't we overcomplicating the supposedly simple and "stupid" pubsub module by pushing all these events into a collection? Wouldn't it be more efficient to just have services subscribe to to these events, and then have the pubsub simply send out notifications that the event happened, and then let the services appropriately handle that event internally?

    My concern is that as the handlers get more and more complex, wouldn't it be better to spread out the load? Let's say there are 50 subscribers to one event, and each of the handlers within those services needs to run 5 functions on average when that event happens. Do we want to run 250 functions within the pubsub service, or send out 50 simple requests to the services to let them know the event was triggered, and have them all execute their handlers individually?

  24. A quick question here. Why 'pubsub.fn(…)' works in people module without importing(or requiring) the js file? Is it because every js files are already loaded in the html file?

  27. I already pay for Laracasts, TreeHouse and CodeCourse. I guess I'm going to have to give you my money too. I'll support your channel but if you have a website, which I didn't see anywhere (so I'm possibly blind) I will buy you lunch each month for videos like this. Really great job man.

  28. Is it a fair assumption that you can only use a mediator when you do not need any information in return? For example, if I wanted to make sure all the names only contained a-z, I wouldn't be able to just fire a message into the ether, right? I'd probably choose to couple my validation logic?

  36. I came up with a slight variation on the revealing module pattern that allows you to raise and handle events that doesn't require a separate pubsub module. Rather than returning your api from the module as an anonymous object if you declare it as a variable you can trigger events on it that can be listened for externally (or internally if you need).

    var controller = (function()
    {
    function doAThing()
    {
    $(interface).trigger("complete");
    }

    var interface = {
    doAThing: doAThing
    };
    return interface;
    })();

    $(controller).on("complete", function() { console.log("Thing Done"); });
    controller.doAThing();

Leave a Reply