Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavioral objects for hub runner #196

Open
EyalAr opened this issue Jan 14, 2015 · 1 comment
Open

Behavioral objects for hub runner #196

EyalAr opened this issue Jan 14, 2015 · 1 comment

Comments

@EyalAr
Copy link
Member

EyalAr commented Jan 14, 2015

Have support in the hub for custom behaviours of handlers based on returned types.

Imagine this could work:

// Widget 1:
define([
    "troopjs-widget/component"
], function (Widget) {
    return Widget.extend({
        "hub/topic": function(){
            return Aggregate("FOO");
        }
    });
});

// Widget 2:
define([
    "troopjs-widget/component"
], function (Widget) {
    return Widget.extend({
        "hub/topic": function(){
            return Aggregate("BAR");
            // Aggregate is a custom return type which
            // aggregates return values of all handlers of this hub topic.
        }
    });
});

// Service:
define([
    "troopjs-core/component/gadget",
    "troopjs-core/pubsub/hub"
], function (Gadget, hub) {
    return Gadget.extend({
        "sig/start": function(){
            return hub.publish("topic").then(function(data){
                // 'data' is an aggregation of the return values of
                // all the handlers for this topic
                console.log(data); // ["FOO", "BAR"]
            });
        }
    });
});
@mikaelkaron
Copy link
Member

How would one indicate to the runner that the return is of a behavior type?

My personal feeling is that instead of having a registry (the first thing that jumped into my mind) we should have a way of ducktyping behavior enabled return values. This would reduce the amount of boilerplate needed and would probably be efficient enough.

Remember that this is somewhat hot code (every handler for any message passed).

Also, in what runners do we need this? From my understanding only the hub runner would need this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants