Have you ever written a tutorial or designed an API? Doing either is way more subjective than you’re implying. Things simply aren’t that cut-and-dry. With tutorials, figuring out which audience to write for and what voice to use are thorny issues.
And yes, there are different standards groups with different conventions. Reconciling them is a major architecture infrastructure headache. Hell, we can’t even standardize on ES6 vs Coffeescript in the Meteor ecosystem.
So, what I’m saying is that it’s best to optimize for devops in production. Name things in whatever way that allows your devs to trace data flows most efficiently. Don’t be obliged to continue using training wheels just because the tutorial uses a lowercase capitalization for collection names (ultimately, it’s a fairly trivial issue). Unless your devs are all going to be junior Mongo devs who need to constantly reference documentation… devops optimization would then be to keep it lowercase.
Honestly I feel like this doesn’t need to be a big deal. If you think lowercase is better, then do that. The Meteor code style police isn’t going to hunt you down if you use lowercase letters.
Surely it’s preferable to align your documentation with the documentation of the underlying service that you are calling?
Your first reason for not doing so suggests you were unaware of the inconsistency which is fine, but now that you are, is there a good reason to not be consistent?
Thanks - naturally I’m going to do what I feel is right. What I’m trying to do here is contribute on a (granted minor) inconsistency in the guide. It is somewhat disappointing to get the impression that resolution here seems to be “agree to disagree”, when you haven’t tried to convince me that capitalisation is better than consistency?
I hear you - my point is simply this: In code, in general, where you can find an established pattern, it is almost always preferable to follow the pattern for consistency, rather than inventing something new no matter how trivial it may seem.
Of course every rule has exceptions, and you and others in their circumstance may have very good reason for doing something your own way.
In this case, however, we are talking about a tutorial. The simplest, most general case. I don’t believe in this instance there is justification for inconsistency (however minor) between the documentation for Meteor and the documentation for MongoDB.
Then submit a pull request with the edits. Personally, I think it’s a mountain out of a molehill. But if it matters to you, make the edits, and submit them for review.
If you have a publication on the server which uses the underlying pub/sub methods (this.ready, this.added, this.changed, this.removed) you can publish data to a client-only collection with a name (in fact you need the name to identify the collection). As long as your new Mongo.Collection('abc'); is run on the client only (not imported or otherwise made available to the server) that will work.
However, if you mutate the data on the client, then the client will attempt a method call to the server to reflect that mutation on the MongoDB collection - but there is no collection, since the server is unaware that you have done this. That will generate a warning on the console, but more importantly, will undo the mutation (because it was not successful on the server).
Why do you want a local collection with a name?
const Bob = new Mongo.Collection(null);
const Carol = new Mongo.Collection(null);
are different local collections and are uniquely identifiable.
I want a local collection with a name because only named collections appear in Meteor Toys. I recently found a way to do this without having it attempt server calls.
I have been following the guide and get to the Collections page when I run into trouble. I am pretty sure I have followed each step correctly (I checked with the github pages). But the local database doesn’t seem to be getting any published documents from the server. So my list is empty. I checked that autopublish is installed. I also cloned the final project and it runs fine.
I am running 1.6 on a new install. I could start with the cloned final application and work backwards until it stops working but there is a lot of room for error in that.
One other point is that the global variable “Tasks” is not accessible in the browser console at all.
Yes you are right, I got the 2 confused since they mirror each other closely. Is there a better forum to post this issue? I did uncover that the tutorial, if cloned from github is running on 1.4 not 1.6.
