My db setup is this:
Somewhere, where the video will be displayed, I also want to display the number of comments a video has. Just getting the comments.length isn’t enough as I also consider the number of replies as comments too.
So I have two options:
A) Have a variable in the Object collection, ‘numComments’ and increment/decrement that whenever I make changes to a comment and its replies. This is more unreliable and can screw up if comments get deleted not properly.
B) Subscribe to the comments collection and figure out how many replies there are. This option takes up less space in the db, (1 less variable), but can be slower and maybe screw up performance, if I subscribe to too many subscriptions (which is why im here asking this).
Which approach would be best for Meteor and how many Subscriptions is too much for a single component? (10?)
I think you should use a tree structure for your comments. Here’s an example of a parent tree data structure: https://github.com/BitSherpa/EverestCamp/blob/master/lib/collections/nodes.js
In result you only need one subscription for the comments of a video. Displaying the hierarchy of replies is done by quering the parent property of your comments.
In case this is not what you are looking for, make sure to give some more context on your problem.
Yes, I forgot to add some more context to my problem.
Btw, I am using react-komposer so I use subscriptions to get query data in the container before being passed into the actual component itself.
In my example, I will obviously need 1 subscription if I go for option A, i.e. the subscription for the Object collection.
If I only had comments in a video, then I would definitely go for option B, with 2 subscriptions, i.e. Object and Comments.
However, I have more than just comments. I might add other arrays of ids, e.g: an array of video id’s (Object collection) of “related videos”.
My worry is that I might be subscribing to too many subscriptions, should I have the need to keep adding more and more to the object, in terms of features.