EngrAhsanAli/MeteorDDP

MeteorCollections API is confusing

Opened this issue · 2 comments

Usually in Meteor, a Collection is defined by its collection name. You will then subscribe to publications, and the collections track any changes caused by these subscriptions.

In this library, a MeteorCollections (why the plural?) is bound to a specific subscription instead, so it will hold the data provided by this subscription only.

Also, if things are setup this way, one cannot really track Meteor's own user collection properly. The reason is that Meteor sends basic information about the user on login, which is not part of a publication, e.g. the username.

How would I track this? Currently, the only way to do this is to user meteorClient.subscribe and then check the low-level documents send from this subscription.

Also, if I have multiple subscriptions for the same collection, these would have to have their own MeteorCollections instance. Which also means that the data would not be merged.

I would recommend re-implementing this in the way Meteor does it, i.e. setting up a collection with its name and then automatically fill its documents from the collection add/change/remove messages coming from subscriptions. This is also the way it is implemented in this C# DDP library for Unity, for example:

https://github.com/green-coder/unity3d-ddp-client

This way, subscriptions to the Meteor users collection would also work as expected and deliver the initial fields of the user document as well.

If one would really need specific collections that only reflect changes for one particular subscription, one could setup a local (client-side) collection, like Meteor supports it in its web frontend. Yet the default should be document merge.

It's actually even more confusing.

If I call MeteorCollections.subscribe(), the name provided has to be a valid publication name. Otherwise you'll get a server error. This is expected behaviour.

However, if I then add a collectionDidChange handler to the MeteorCollections object, this will only notify about a change if the collection name (!) was used for the publication name. This fails if the collection name is different. They only reason this works in the example project is that both names are the same. It does not even work if you add the collectionName parameter when subscribing.

Also, I noticed that the fields returned by the server are not merged into the target document held by the MeteorCollections.documents dictionary. While cleared properties will be cleared, the added properties just override the entire document. So previous updates to the same document get lost.

Hi

I couldnt understand they way you want to listen your collections though MeteorCollections (the reason for plural as this class handles multiple collections internally and responsible to provide the callbacks for subscribed events)

To listen for users, you can subscribe the "users" collection for the event, this would be as same as your custom collections changes would be listened through the callbacks.

client.listEventOnce("users", event: .dataAdded) {
            guard let value = $0 as? MeteorDocument, value.id == self.meteor.userId else { return }
            // Login successful 
}

P.S: There are other events for login events but above one is just an example.