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

Subscription enhancements request #2052

Closed
3 tasks
nirinchev opened this issue Oct 5, 2018 · 3 comments · Fixed by #2060
Closed
3 tasks

Subscription enhancements request #2052

nirinchev opened this issue Oct 5, 2018 · 3 comments · Fixed by #2060

Comments

@nirinchev
Copy link
Member

nirinchev commented Oct 5, 2018

To provide a nicer subscribe/unsubscribe API in the GraphQL service, we need the following enhancements to the subscription functionality in realm-js:

  • Ability to unsubscribe by name. There should be no reason to subscribe to something only to later unsubscribe.
  • Ability to list all active subscriptions. We already have that information in the partial Realm, so there should be no reason not to expose it. I need just the name and the query and not a reference to the subscription instances or anything like that.
  • A nicer wrapper around waiting for subscription - something like:
return new Promise((resolve, reject) => {
  const listener = (__, state) => {
    switch (state) {
      case Realm.Sync.SubscriptionState.Complete:
        subscription.removeListener(listener);
        resolve();
        break;
      case Realm.Sync.SubscriptionState.Error:
        subscription.removeListener(listener);
        reject(subscription.error);
        break;
    }
  };
  subscription.addListener(listener);
});
@cmelchior
Copy link
Contributor

Ability to list all active subscriptions. We already have that information in the partial Realm, so there should be no reason not to expose it. I need just the name and the query and not a reference to the subscription instances or anything like that.

IMO we should just expose the __ResultSet as a Subscription. I suspect that trying to do anything else is going to bite us later.

@nirinchev
Copy link
Member Author

I'm not against that, but if we decide to do that, we should enhance the Subscription interface and add properties for the name and the serialized query. Otherwise it's fairly useless to get a list of these.

@cmelchior
Copy link
Contributor

Yup. For bindings that support the text-based parser, they could also enable directly returning the Results object.

Java is currently a bit hampered in that regard, but just exposing a text-based description + name seems fine for a first iteration.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants