Add server support for Counts.get and Counts.has

[gbhrdt]

should fix #80

[boxofrox]

Unless I missed something, countsCollection is never written to, only read from, which means countsCollection.findOne() always returns null.

This patch is essentially...

Counts.get = function countsGet(name) {
  return 0;
};

Counts.has = function countsHas(name) {
  return false;
};

While this will prevent fatal errors with server-side rendering, I have reservations that users will appreciate the server-side rendering all counts as zero. Principle of Least Surprise and all that.

I would rather users decide for themselves how to handle this situation. The following user-defined function would provide the basis which allows users to define how server-side-rendering behaves... at least for simple counts.

// lib/count_helper.js

// only necessary if you wish to count on the server side with Collection.find().count().
var collectionMap = {};

if (Meteor.isServer) {
  collectionMap = {
    things:   Things,
  };
}

function getPublishedCount (name) {
  if (Meteor.isClient) {
    return Counts.get(name);
  }
  else {
    // decide whether to return 0, or return
    // collectionMap[name].find().count(), or etc.
  }
}

function hasPublishedCount (name) {
  if (Meteor.isClient) {
    return Counts.has(name);
  }
  else {
    // decide whether to return false, or return true, etc.
  }
}

if (Package.templating) {
  Package.templating.Template.registerHelper('getPublishedCount', function (name) {
    return getPublishedCount(name);
  });

  Package.templating.Template.registerHelper('hasPublishedCount', function (name) {
    return hasPublishedCount(name);
  });
}

Meteor's load order should ensure the template helpers are replaced with these functions, and that's only necessary if you use the helpers. Otherwise, use the *PublishedCount() functions directly.

I'm not entirely opposed to merging the all-counts-zero patch above, but I feel that this band-aid only hides a noisy & apparent problem--that forces the user to address the issue in a way acceptable to their needs--with a silent and potentially unexpected behavior--all counts zero--that may not be addressed at time of deployment.

As always, I defer to the judgement of @tmeasday and the other senior developers.

[boxofrox]

I can see that users might populate countsCollection in their code, at which time some counts would be available server-side.

I don't see this case as an implementation that would handle all use cases, and still prefer users--that implement server-side-rendering--to apply a solution that fits their needs.

Here's one example. A parameterized count limits a client to only that information which they are allowed to count. These counts are dynamic and difficult/inefficient to pre-cache for a large user-base, or for counts with multiple parameters.