Realtime: how to subscribe to multiple documents

[bnetter]

What's the equivalent of listening to multiple documents in a collection using the realtime-listener service?

I have a news-feed component where I'm trying to watch for new activities. Here's my activities computed property:

activities: computed('company', function() {
  return this.get('store').query('activity', {
    query: (ref) => ref.where(`company`, '==', this.get('company.id')).orderBy('createdAt', 'desc');
  });
})

That's fetching correctly current activities, but it's not updated live. How do I achieve that? I've tried the following:

this.get('realtime').subscribe(this, this.get('activities'));

It's obviously not working as the second parameter has to be a record, not an array.

[bobmosh]

I'd love to know that too. However I can't even get a subscription to a single document to begin with. Anyone here who can help with the subscriptions?

[bnetter]

@bobmosh you can probably find some indications in the #576 issue I created.
@jamesdaniels any chance to get this to work somehow?

[jamesdaniels]

I've not implemented computed property / promise proxy awareness in the service yet, I'd welcome a PR. It could probably be implemented without a lot of hackery, at the very start of subscribe. Else I'll see about getting to it after I get includes support for RTDB & many-to-many relationships working.

[bnetter]

When are you planning to work again on the package then @jamesdaniels ?

[jamesdaniels]

@bnetter I will be doing more work on emberfire this week but I don't think I'll have a chance to get to this issue. I am planning on getting the documentation, particularly the migration guide, to a good spot so we can release 3.0 stable ASAP.

[bnetter]

Hey @jamesdaniels, any news?

[bnetter]

Hey @jamesdaniels, news?

[bnetter]

Hey @jamesdaniels ?

[zurnet]

Happy New Year!

@jamesdaniels curious as well in terms of the state of emberjs ? I was hoping to use Firestore but am at a standstill until docs and final release for v3 of this project are updated

Any ETA or news you can share ?

[bnetter]

I have a meeting next week with the Google team in SF. I will discuss the frustration it has been to work with Firebase, and will try to understand if we can still have hope for Firebase in 2020.

I will let you know!

[jamesdaniels]

@bnetter I understand that you're feeling fustrated but please keep your comments constructive. The space here is meant for building EmberFire, both technology and community. If you're interested in helping with the former, I welcome any PRs; otherwise please consider if you are helping or harming the latter with your comments.

@zurnet I'm back from the holidays and will be wrapping up the tasks for final release in short order.

[bnetter]

@jamesdaniels when was the last time you had to fix Netflix software? We pay on a monthly basis for Firebase, I don't understand why it would be my responsibility to fix this package.

If you want me to work on this package, either Google would have to pay me, or Google would have to release this package back to the community.

[jamesdaniels]

@bnetter this is an MIT Licensed and community driven effort. Just because our NPM tokens are encrypted doesn't make this any less true, that's just a security best practice. In fact there are 4 individuals outside Google with write privileges on this repository. If you or other community members wish to exercise more control you just need to post proposals, drum up support, and ship it. You can do that here or fork the repository, I'm open to either. It doesn't matter to me if this community is "owned by Google" or not, I'm sure we could move over NPM ownership if a fork became more popular and better maintained.

If you or your customers have an SLA with Google, this is not the correct medium for exercising that level of support; our GitHub Issues are addressed in a best-effort basis.

If large customers, important to Firebase, depend on EmberFire I'd appreciate a heads up privately. I have no way of knowing that. All I have as a mechanism for prioritizing my Github work and showing my individual impact is community response, Github issues, NPM downloads, and number of stars on the repository. We are working on a PlatformLoggerService in the JS SDK that I could hook into but that effort is still some time away from our being able to differentiate EmberFire usage from any other Javascript library in our backend dashboards.

That stands too for paying third parties to help us with maintenance of framework-specific libraries, this is something we do but we need to know that people depend on it.

Finally, as I've stated, this is not the correct medium for venting frustration. Please moderate your communications. I know you think you are helping, but to be honest, it's doing the opposite. If I lose motivation to work on this and community members are pushed away then it's likely there will be no EmberFire.

[bnetter]

1. I don't see why I have to sign a Google Individual Contributor License Agreement if it's MIT licensed. I quote:

You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

2. I would argue the way you prioritize your work is wrong: of course a car with 2 wheels wouldn't sell well. It's exactly where we are right now with this package, you have to be honest: basic Firebase functionalities are not working at all, and the coding experience is… frustrating. You can't judge the usage on a broken package.

3. This package has an impact on my work life. Because I'm relentless, I'm still using Firebase. Obviously if I was starting again today, knowing this package would be so painful to use, I would just not use Firebase at all. I'm sure this is discouraging more people than you think of actually using Firebase.

[jamesdaniels]

As for 1, that's corp Github policy. There's a lot of reasons for that; one that strikes me might be relevant to you. I'm not a lawyer but if your customer were under an SLA, it's possible they could get a different license for libraries such as this; whereas MIT comes with zero guarantees / liability. It's ensuring that we don't have to hunt down every developer who's ever contributed to relicense, etc. Many large open source projects do something similar.

Re 2&3, the current state of affairs is getting about double the number of downloads and much more in the way of traffic than the EmberFire library ever got in the past. Far less issues filed too and a much smaller codebase, yes it's a WIP but a lot easier to work with and understand than version 2. Before the library hadn't achieved fit with the market, I think we're closer there.

Yes, there are still things version 3 can't do as well as version 2 but I think there are more pros.