In our app, we’re displaying excerpts of the same collection at different places in our UI. All publications have different parameters. Since all data will be merged by Meteor’s merge box, it can happen that documents show up in one section of the UI although they shouldn’t, unless we filter the client-side fetches accordingly, which can become pretty complex.
I know that an alternative way to do this is using low-level publishing to “pseudo-collections” that only exist for the purpose of one publication. However, this is pretty tedious and requires a lot of boilerplate. Is there any solution (package) out there, that makes this easier? Just like: subscribe to this collection, but report the results as another (pseudo) collection?
I tried out subscription-scope now. It works as a charm! Do you happen to know if scoping a subscription will impact the other subscriptions (to the same collection), if they use a regular query instead? Or, putting it another way: Is it possible to mix scoped and unscoped subscriptions to the same collection?
I’m generally curious how this works under the hood. If two (scoping) subs contain the document, will it appear in both, but transmitted only once?
Ok, I experimented a bit further with this package. It seems as if it has some major drawbacks: Since it adds another key to each document (containing the subscription ID), the server has to send a change message for each and every document once the subscription changes. This seems to be necessary for the mechanism to work, but it causes significantly more network traffic, especially if you have a lot of documents like in my location-based app where documents are displayed on a map.
Also, I noticed that if there are two scoped subs referring to the same collection and you modify the parameters of one of these subs, a “flash of content” appears in the other subs. I haven’t found out yet why this happens, but it seems as if the other subs have to rerun because they have to decide whether their documents are included in the scope again. In my map app, for instance, I have two subs on the same page: one that shows pins on a map, based on the map section displayed. The other is a feed of the recent pins that have been dropped. Even if on the map only one pin is visible (high zoom level) and I move the map a bit (which normally would cause no changes), the other sub (with the feed) updates all of its documents and flashes for a short time period.
I think I have to revert back to using manual queries to separate the subs, although this is pretty cumbersome if you have complex queries that then have to run on both server and client-side to sort things out.
Yeah, unfortunately I’ve not used the package so I’m not privy to its inner workings, caveats, or drawbacks. Honestly I switched to cultofcoders:grapher for new projects some time ago and it alleviates this problem as well as lets me optimize with non reactive queries extremely easily as well.
Interesting. Does grapher support reactive queries? Or does Meteor + Apollo already have subscriptions? Last time I looked (pretty long ago), the subs stuff was still in the make.
Yes, grapher supports both non reactive and reactive queries. As far as graphql, I haven’t looked at it in quite some time. Last time I did it was far more of a headache than using live data for smaller projects, that didn’t need to scale, or grapher for those that did.
I can recommend reywood:publish-composite for this use case, as you can give composite publications their own name. You can compose one publication from one collection to emulate a normal publication, this works quite well. It can be integrated into an existing Meteor application in an easy way, you don’t need to worry about existing publications. See The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere for more details.
In recent projects, I’ve used cultofcoders:grapher, but changing to it needs more modifications.
Interesting. I’m already using publish-composite, but only for those pubs that need joins. Didn’t realize it supports different collection names as well. Usually, I try to avoid using it unless it is necessary, because the joins are pretty inperformant. But this won’t apply here, I guess, so I’ll give it a shot. Thanks for pointing me to this!
Hey, just wanted to report back that publish-composite did the trick. Couldn’t find any downsides so far. This helps to make the client code so much simpler. Thanks again for pointing me out to this option!