Handling changing dependencies of subscription about swiftddp HOT 13 CLOSED

Right now, I believe you'll need to unsubscribe/resubscribe with new arguments to get this behavior. This pattern tends to work much of the time in iOS - subscribe in viewWillAppear() and unsubscribe in deinit().

That said, I am looking at changing this behavior in the next release. To be clear, where is the quoted text from?

from swiftddp.

Thank you for the fast reply! I've tried to follow your advice but I'm not sure if I got it right. My approach:

    var coords = [String: Double]() {
        didSet (previousCoords) {
            if coords != previousCoords {
                Meteor.unsubscribe("deals/list" ) {
                    Meteor.subscribe("deals/list", params: [self.coords]) {
                        self.appDelegate.listsSubscriptionIsReady()
                    }
                }
            }
        }
    }

which does not quite work. Could you elaborate how to re-subscribe correctly?

Also, I wondered if it might be more efficient to use CoreData instead and do the filtering logic on the client side. But this would somehow kill the intended reactivity.

Sorry for leaving out the source. It can be found here.

from swiftddp.

Cool. Thanks for the link to the Meteor Guide. It wasn't around when I wrote the first draft of this code.

While that's not quite the way I'd do it, it looks plausible. How does it not quite work? i.e. what behavior are you seeing?

from swiftddp.

I think that SwiftDDPs behavior should be changed to be in line with the Meteor guide. I'll try to make the changes and test them out this evening (US eastern time). Barring unforeseen complication, will that work for you?

from swiftddp.

Thank you very much for your help! If I could somehow assist, I'd be very happy to do so.

from swiftddp.

If you'd like to take a crack at the changes, I'd be more than happy to merge a pull request. Otherwise, you can help test the changes.

from swiftddp.

I think I'd go for testing the changes as I'm not considering myself to be qualified enough to implement the changes.

from swiftddp.

So after reading the Meteor Guide a little more carefully, I think this is a little more complicated and nuanced than I initially thought. I will have to finish it this weekend.

In the meantime, you can still sub/unsub. If you subscribe in viewWillAppear() and unsubscribe in deinit(), this is the same behavior you describe in the Javascript code at the top of this thread. There, you are subscribing when the template is created, and the subscription is automatically terminated when the template is destroyed. This is the same as subscribing when a view is created and unsubscribing when a view is removed. Because we don't have tracker in iOS, you have to implement this yourself by manually calling unsubscribe when the view will disappear. Make sense?

from swiftddp.

So there's a dev branch that now allows subs to be modified with new arguments. As with Meteor, changing the sub with new arguments actually creates a new sub and your collection will be the union of the two subs. You can now either unsubscribe to all subscriptions to a publication, or you can unsubscribe to specific subsets using the id that the subscription function returns. This is how Meteor/Tracker works under the hood.

This is going to break the api a little because it will make callbacks more complicated to implement on unsubscribes, but I don't think that will be too big a deal.

Give it a try.

from swiftddp.

Thank you for your efforts! I really appreciate the work and time you've already put into this.

I wasn't able to unsubscribe on the event of a changing param yet. Whenever I'm attempting to do this, SwiftDDP outputs:

[Debug] [DDP] [0x124e3d160] [260] ddpMessageHandler > Received message: {
    id = "deals/list";
    msg = nosub;
}

I'm using still using the approach described above. Could you share the way you're doing it?

from swiftddp.

So, to confirm, you're on the dev branch.

You subscribe like this:

var subscriptionId = Meteor.subscribe('foo', ['123456'])

This creates a subscription for all records that match 123456. You can do this again with different arguments:
var subscriptionId2 = Meteor.subscribe('foo', ['789'])

You are now subscribed to all records that match the sub with parameters 123456 and 789.

You unsubscribe like this:
Meteor.unsubscribe(withId: subscriptionId)
This unsubscribes you ONLY to the records that correspond to the argument 123456. If you have also subscribed with parameters 789, you're still subscribed to those.

var allIdsYouUnsubscribedTo = Meteor.unsubscribe('foo') removes all subscriptions associated with 'foo', regardless of parameters. If you do that a second time you get 'nosub', because there are no longer any subscriptions to 'foo'. If you want to have fine-grained control over your subs by changing the parameters, avoid unsubscribing by name.

from swiftddp.

Works as aspected. Thank you very much for your help and the guidance. Let me know if there is any way to support your work - I'd be honored.

from swiftddp.

No problem. I'd like to continue to test this some more before adding it to a production release. You can help by working with it and letting me know how it works.

from swiftddp.