Add optional transform function to options

[DeanKamali]

I needed to make changes to aggregate results before sending it to the client.

In my use case, I needed to further modify the aggregation results and calculate the result of a number of fields via math library extact-math which was difficult for me to do in mongo.

I have added an optional function to be executed before sending the document to mini mongo.

import { ReactiveAggregate } from 'meteor/tunguska:reactive-aggregate';

Meteor.publish('nameOfPublication', function() {
  ReactiveAggregate(sub, collection, pipeline, {
      transform: doc => {
          // make changes here
      }
  });
});

[robfallows]

@DeanKamali : You can add a transform when you define the collection. For example, editing one of the README examples:

import { Mongo } from 'meteor/mongo';

// Define a named, client-only collection, matching the publication's clientCollection.
const clientReport = new Mongo.Collection('clientReport', {
  transform(doc) {
    const newDoc = { ...doc };
    newDoc.totalTimeSpent = doc.hours * doc.books;
    return newDoc;
  }
});

Template.statsBrief.onCreated(function() {
  // subscribe to the aggregation
  this.subscribe('reportTotals');

// Then in our Template helper:

Template.statsBrief.helpers({
  reportTotals() {
    return clientReport.find(); // will now include totalTimeSpent in each doc
  },
});

Is there any reason why the inbuilt collection#transform will not do what you need?

[DeanKamali]

@robfallows transform function Is only available on the client, not on the server, that's why I wanted to modify the documents before sending them to the client.

[robfallows]

@robfallows transform function Is only available on the client, not on the server, that's why I wanted to modify the documents before sending them to the client.

No. It is available on the client or server:

However, as this package creates a publication using Meteor's pub/sub API, it's expected that it will be consumed by a subscription. That will normally be on a client (browser) but can be on a server (for example in a microservice architecture).

The transform data will only be available when the cursor is evaluated (.fetch() or .forEach() for example). That's equally true for a minimongo cursor returned by this package.

[DeanKamali]

@robfallows You are correct; however, the transform function that I added, will target the results of aggregation vs. transform function that will target documents from a single collection, it's like performing another $project on the server-side.

If my case, I could have done the whole transformation in Mongo, but I will end up with a lengthy & complex pipeline vs. a few lines of code on the server-side.

[robfallows]

If the collection contains only the results of the aggregation - which is typically the case - then there is no difference, surely?

[smohantyCME]

Is there a reason we cannot merge this? I have the same use case as @DeanKamali where I really only want to perform some modifications on the Server prior to publishing to client. I don't want to introduce a separate transform function on the Schema definition

[robfallows]

I think we can move forward with this once the following have been completed and approved:

1. Update README.
2. Update changelog (History.md).
3. Update package.js.
4. Update code to include pre-check and appropriate error logging for the new transform property (i.e. if it's present it's a function).

[vbgm]

+1 to this