Request for additional utils

[estaylorco]

Request for additional utils

[ifandelse]

Hey @estaylorco - I'm definitely open to something like this. I'm working on the v0.9.0 changes, so I could look at including it in that. Bear with me - just had our 3rd baby, so things have been a bit busy here, but I plan to have v0.9.0 locked down and out this month.

[estaylorco]

@ifandelse - Thanks for the consideration...and congrats on your 3rd! I just finished converting my Durandal-based datepicker to postal. Works like a charm! With pub/sub, I had multiple instances responding to the same set of messages (and trying to guard with a unique id), but it just wasn't reliable. Wonderful to have actual channels! Thanks for your hard work.

[ifandelse]

@estaylorco I finally have some time carved out today & tomorrow to work on this. I simultaneously laughed/cried when I saw my earlier comment of having 0.9.0 "out this month" three months ago. "Past" me is always an idiot, making "future" me mad all the time. :)

[estaylorco]

@ifandelse No problem...and I'm so glad you are turning your attention to this! I'm looking forward to eliminating this in my detach handlers:

MultiAddressFreeForm.prototype.unregisterSubscriptions = function () {
        _.each(this.subscriptions, function (sub) {
            sub.unsubscribe();
            sub.callback = null;
            sub = null;
        });

        this.subscriptions = null;
};

It may be that we need to introduce context, where, for example, there might be one additional utility:

utils.unsubscribeAllIn( channel, topic, context )

There could be active subscriptions outside the current context, and without being able to narrow the scope, those subscriptions could inadvertently be unsubscribed. Conceptually, we're talking this:

foreach subscription in subscriptions
    if subscription.channel === channel AND subscription.topic === topic AND subscription.context == context
       then unsubscribe

if that's possible.

[ifandelse]

@estaylorco Does it bother you if I keep to an options-object argument approach, like this:

postal.unsubscribeAll({
    channel: "someChannel", // optional, defaults to "/",
    topic: "some.topic", // optional, defaults to "#" (so it uses the bindings resolver to match for topics)
    context: someInstance
});

My thought is, support an options object like the above example, and also a predicate function as an overload....which gets used in a forEach over the subscribers, and is passed the subscription definition, and if it returns true, unsubscribe happens, etc. The predicate would be for customized scenarios (where the SubDef has been given additional props, etc.).

[estaylorco]

@ifandelse No, not at all. It's an approach that's consistent with the rest of the API. I was illustrating more in the abstract than anything else. And, yes, a predicate makes sense as well.

[ifandelse]

@estaylorco - check out the rc2 tagged release: https://github.com/postaljs/postal.js/releases/tag/v0.9.0-rc2.

The syntax works like this:

// unsubscribe EVERYTHING (the nuke it from orbit option):
postal.unsubscribeFor();

// unsubscribe everything on the ui channel
postal.unsubscribeFor({
    channel: "ui"
});

// unsubscribe any subscribers on the data channel
// that would match a topic of item.new
postal.unsubscribeFor({
    channel: "data",
    topic: "item.new"
});

// unsubscribe everything with the "viewModel" set as the context:
postal.unsubscribeFor({
    context: viewModel
});

The options object above is actually a shortcut to using the "predicate" API:

postal.unsubscribeFor(function(sub) {
    return sub.someInstanceProp === "hai mom" && !sub.inactive;
});

[estaylorco]

@ifandelse So, then, if we want the following,

postal.unsubscribeFor({
    channel: "data",
    topic: "item.new"
    context: viewModel
});

we would simply use a predicate? Or do you see that being handled by the above?

[ifandelse]

@estaylorco Sorry Eric - I should've mentioned that you can pile on as much as you want in that options object - so channel, topic & context like you have above is just fine. In fact, if you had added a custom instance prop to your subscription definitions, you could include it there as well:

postal.unsubscribeFor({
    channel: "data",
    topic: "item.new"
    context: viewModel,
    someCustomInstanceProp: "I like big variable names...."
});

When you use the options object, the comparison underneath effectively compares the props you provide on the options arg to the props on the SubDef (with a mild caveat that topic is compared via the bindings resolver, not straight string comparison, and context comparisons have a special case, too, but nothing you have to worry about).

[estaylorco]

@ifandelse Ah, OK. That makes sense. I wasn't sure how you were implementing filtering.

[ifandelse]

Closing this out - keep me posted if you have any other questions, etc. Thanks!