Meteor: Unintuitive error if using field: {_id: 0} inside Tracker.autorun

[mitar]

This simple code snippet fails:

Tracker.autorun(function () {
  console.log(collection.findOne({}, {fields: {_id: 0}}));
}

With:

Error: You may not observe a cursor with {fields: {_id: 0}}

This is normal, because reactivity uses observe internally. But this is not really intuitive to the end user. It would be great if this would work (and internal observe could use _id field, but not expose it), or if error would be a bit clearer for people who do not know internals. (Imagine that this call is somewhere deep inside the reactive context.)

[glasser]

Good point; this is confusing.

Making this would would be sort of intricate. The chain is findOne -> fetch -> forEach -> _depend -> observeChanges. You could do a hacky sort of thing where if _depend is told that it's for a findOne, and if it's _id: 0, then it strips the _id: 0 from the observeChanges call, and then also strips the _id field from what's returned? Seems more complexity than it's worth.

But you could make _depend pass a private flag to observeChanges which makes it print a different error message in this case, saying something about how you can't make a query inside a "reactive computation" (that's the phrase used in the docs) with _id: 0, unless you also pass reactive: false.

[mitar]

Yea, I know it is probably too much work for what is it worth. I mostly wanted to document it here so that people searching for this error will get an insight into the cause.

[hwillson]

There hasn't been any activity on this issue in a while, and as mentioned in previous comments the amount of effort/complexity needed to resolve this issue won't really be worth it in the end (due to the very low chances of people running into this issue). I'll close this for now (and to address https://github.com/meteor/meteor/issues/4004#issuecomment-86716897 - anyone running into this issue will still find this issue thread in the closed issues). Thanks for reporting this originally!