CODEWITHSUNDEEP
javascriptdesign-patternsbackbone.jsrequirejspublish-subscribe
user2736286
user2736286

Reputation: 563

How can I make this pub/sub code more readable?

I am investigating the pub/sub pattern because I am reading a book that highly advocates event driven architecture, for the sake of loose coupling. But I feel that the loose coupling is only achieved by sacrificing readability/transparency.

I'm having trouble understanding how to write easily-understood pub/sub code. The way I currently write my code results in a lot of one-to-one channels, and I feel like doing so is a bad practice.

I'm using require.js AMD modules, which means that I have many smaller-sized files, so I feel like it would be very difficult for someone to follow the flow of my publishes.

In my example code below, there are three different modules:

  1. The UI / Controller module, handling user clicks
  2. A translator module
  3. A data storage module

The gist is that a user submits text, it gets translated to english, then stored into a database. This flow is split into three modules in their own file.

// Main Controller Module
define(['pubSub'] function(pubSub) {

    submitButton.onclick(function() {
        var userText = textArea.val();
        pubSub.publish("userSubmittedText", userText);
    });

});

// Translator module
define(['pubSub'] function(pubSub) {

    function toEnglish(text) {
        // Do translation
        pubSub.publish("translatedText", translatedText);
    };

    pubSub.subscribe("userSubmittedText", toEnglish);

});


// Database module
define(['pubSub'] function(pubSub) {

    function store(text) {
        // Store to database
    };

    pubSub.subscribe("translatedText", store);

});

For a reader to see the complete flow, he has to switch between the three modules. But how you would make clear where the reader should look, after seeing the first pubSub.publish("userSubmittedText", userText);?

I feel like publishes are like a cliff hanger, where the reader wants to know what is triggered next, but he has to go and find the modules with subscribed functions.

I could comment EVERY publish, explaining what modules contain the functions that are listening, but that seems impractical. And I don't think that is what other people are doing.

Furthermore, the above code uses one-to-one channels, which I think is bad style, but I'm not sure. Only the Translator module's toEnglish() function will ever subscribe to the pubSub channel "userSubmittedText", yet I have to create the new channel for what is basically a single function call. While this way my Controller module doesn't have to have Translator as a dependency, it just doesn't feel like true decoupling.

This lack of function flow transparency is concerning to me, as I have no idea how someone reading such source code would know how to follow along. Clearly I must be missing something important. Maybe I'm not using a helpful convention, or maybe my publish event names are not descriptive enough?

Is the loose coupling of pub/sub only achieved by sacrificing of flow transparency?

Upvotes: 1

Views: 923

Answers (1)

orange
orange

Reputation: 8090

The idea of the publish subscribe pattern is that you don't make any assumptions about who has subscribed to a topic or who is publishing. From Wikipedia (http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern):

[...] Instead, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are.

If your running code doesn't make any assumptions, your comments shouldn't do either. If you want a more readable way of module communication, you can use requirejs' dependency injection instead, which you already do with your pubsub module. This way, you could make it easier to read the code (which brings other disadvantages). It all depends on what you want to achieve...

Upvotes: 1

Related Questions