Harry Adel has integrated this package into MeteorJS core starting with version 3.4. We recommend that you switch to the now official approach.
This package gives you utility functions to extend your Mongo.Collection instances in (hopefully) the safest,
easiest and coolest way.
If you want to create a package that monkey-patches the Mongo.Collection constructor, you'll need this package. I am striving for this package to be a third-party official way of monkey-patching Mongo.Collection until,
well, Meteor decides to create a core functionality to properly extend it.
- Starting with v. 1.0.0, this package requires Meteor >= 3.0!
- The module needs to be imported explicitly, it's not a global anymore!
- All extensions will have to use
collectionas first param, instead ofthis:
import { CollectionExtensions } from './collection-extensions'
CollectionExtensions.addExtension(async (collection, name, options) => {
// ... your extension code
})This implies extensions have to be updated accordingly
Furthermore, extensions may not be applied immediately.
This is, since extensions are applied during the call of the Mongo.Collection
constructor. However, constructors cannot be async.
We can't therefore be sure, when (async) extensions have been applied, without using a callback:
const extensions = {
onComplete: () => {},
onError: e => console.error(e)
}
// exentsions options will not be passed to
// the original collection constructor!
const MyDocs = new Mongo.Collection('myDocs', { extensions })This is unfortunate, but a tradeoff between determinism and compatibility.
addPropertynow usesObject.definedPropertyunder the hood and allows to pass in property descriptors as third argument, while the function is always required
With the changes of Meteor 3.0 moving to full async,
we now have to resolve the Promises, returned by
Mongo.Collection methods (insertAsync etc.).
meteor add lai:collection-extensions
Meteor gives you no easy way to extend the Mongo.Collection object, and therefore
package publishers who want to extend its functionality resort
to monkey-patching the Mongo.Collection constructor, and sometimes it's not done right. This package seeks to centralize one well-done monkey-patch with the ability to hook into the constructor as many times as possible. See my code.
I am hoping for all collection-extending package authors to to use this to end the package compatibility issues. In order for this to happen, I will fork major packages like matb33:collection-hooks, sewdn:collection-behaviours and refactor the code to use this utility package, and run their test suites.
If you want to help, that would be awesome.
Pass in a (async or standard) function where the arguments are the same as that of when instantiating Mongo.Collection.
In addition, you may access the collection instance by using this.
Very Important: You need to make sure your extensions are added before you instantiate your Mongo.Collections or your extensions will not work. Most likely you will only use this when building a custom package.
Pass in the name of the prototype function as well as the function. Yes, I know you can simply just do Mongo.Collection.prototype.myPrototypeFunction = function (...) {}, which is fine. One of the things that this function does differently is to check whether you're in an older version of Meteor, in which Mongo.Collection doesn't exist but rather Meteor.Collection does. Note: If you are a package author that adds/modifies prototypes on the Mongo.Collection, this is not so critical for you to use unless you really want backwards-compatibility.
The following code recreates this section of code of the dburles:mongo-collection-instances using CollectionExtensions.addExtension(fn) thereby eliminating the need to monkey-patch the Mongo.Collection constructor:
import {CollectionExtensions } from 'meteor/lai:collection-extensions'
const instances = [];
CollectionExtensions.addExtension((collection, name, options) => {
instances.push({
name: name,
instance: collection,
options: options
});
});The following code overrides ìnsert to use insertAsync under the hood.
import {CollectionExtensions } from 'meteor/lai:collection-extensions'
CollectionExtensions.addPrototype('insert', async function (doc) {
return this.insertAsync(doc)
})Integrate this package into the following packages and test them:
-
matb33:collection-hooks(Refactored and tested with 100% success) -
dburles:mongo-collection-instances(Refactored and tested with 100% success) (Now merged into master!) -
sewdn:collection-behaviours(He didn't write tests but here's the forked refactor anyway in case you wanted to test)
Create tests.
If you are interested in using this package in your package, or if you want me to test (or if YOU want to test it yourself) integrating this into your package let me know and I will add it to the Todo list.
Feedback is welcome.
Add control over the execution order of each collection extension somehow. Track collection instances that were prematurely instantiated and apply extensions on demand. Get Travis CI installed.
MIT, See license file