meteor-community-packages / meteor-collection-extensions Goto Github PK

How about using your own CollectionExtensions "namespace" instead of meteor's Meteor "namespace".

They've advised against using their namespace to prevent future collisions of functionality.

CollectionExtensions.addExtension and CollectionExtensions.addPrototype would be nice.

I'm gonna look into using this package for my zimme:collection-behaviours which is a re-write of sewdn:collection-behaviours package. I've added configuration and a couple of other things and it's used by zimme:collection-timestampable and zimme:collection-softremovable, which have support for aldeed:autoform, aldeed:collection2 and aldeed:simple-schema.

I'm thinking I can use this package for automagically adding the behaviours of the packages to collections.
I just need to figure out a good way to make it respect a user configurable exception list.

This is needed because for now you may only attach a behaviour and not detach it. And even if you wanna have all your collections by default use one of the behaviours you still might not want it on a specific collection.

Ran meteor update a couple days ago and began getting this console warning message.

Meteor.addCollectionExtension is deprecated, please use CollectionExtensions.addExtension

How to fix?

I will fork major packages like matb33:collection-hooks, sewdn:collection-behaviours, dburles:mongo-collection-instances, refactor the code to use this utility package

This was already done (thanks, BTW!)

There are few other extensions which would be great to have an API for:

• extending subscription handle (what is returned from Meteor.subscribe)
• wrapping existing methods on collections (like observeChanges)

I had to do this in these packages:

• https://github.com/peerlibrary/meteor-reactive-publish
• https://github.com/peerlibrary/meteor-subscription-data
• https://github.com/peerlibrary/meteor-subscription-scope

TypeError: Class constructor Collection cannot be invoked without 'new'
W20171223-20:42:43.835(8)? (STDERR) at new ns.Collection (packages/lai_collection-extensions.js:107:27)
W20171223-20:42:43.835(8)? (STDERR) at autoupdate_server.js (packages/autoupdate/autoupdate_server.js:39:18)
W20171223-20:42:43.836(8)? (STDERR) at fileEvaluate (packages/modules-runtime.js:343:9)
W20171223-20:42:43.836(8)? (STDERR) at require (packages/modules-runtime.js:238:16)
W20171223-20:42:43.836(8)? (STDERR) at /Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/packages/autoupdate.js:226:1
W20171223-20:42:43.836(8)? (STDERR) at /Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/packages/autoupdate.js:233:3
W20171223-20:42:43.836(8)? (STDERR) at infos.forEach.info (/Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/boot.js:415:13)
W20171223-20:42:43.836(8)? (STDERR) at Array.forEach ()
W20171223-20:42:43.837(8)? (STDERR) at /Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/boot.js:414:9
W20171223-20:42:43.837(8)? (STDERR) at /Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/boot.js:468:5
W20171223-20:42:43.837(8)? (STDERR) at Function.run (/Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/profile.js:510:12)
W20171223-20:42:43.837(8)? (STDERR) at /Users/monsterstep/dev/meteor-react-router-test/.meteor/local/build/programs/server/boot.js:467:11

After loading this package, the Meteor.Collection object is left halfway between the old state and the extended state. Any package that extends the patched Meteor.Collection using prototype inheritance, such as using Coffeescript class / extends will fail to use the monkey-patched constructor.

Here's the issue where I discovered this: vsivsi/meteor-file-sample-app#2 (comment)

I'm not embarrassed to say that I'm pretty opinionated about this, and I'm going to add more sanity checks and throws to my packages to defend against other packages that misbehave when replacing Meteor provided standard system calls.

IMO, the safe and sane way to extend Mongo.Collection is via a mechanism that supports, e.g.:

extendedCollection = collectionExtend(Mongo.Collection, methods);
collection = new extendedCollection('foo');
extraExtendedCollection = collectionExtend(extendedCollection, methods);
collection2 = new extraExtendedCollection('bar');

If the app developer wants the "convenience" of setting Mongo.Collection = extraExtendedCollection then let that be their choice.

I don't use this package directly (and can't find where it comes from in my system) but I'm always getting this annoying warning in firefox console

mutating the [[Prototype]] of an object will cause your code to run very slowly; 
instead create the object with the correct initial [[Prototype]] value using Object.create

and peace of code:

mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create lai_collection-extensions.js:97:5

I got this error while running a meteor app with this package.

@matb33 said in Meteor-Community-Packages/meteor-collection-hooks#118:

I am, although there's one more thing I think your end needs to handle, which is direct collection access. I'd like to still offer users a way to circumvent collection hooks while still allowing other collection extensions, but it would be great to also offer the option for users to circumvent all collection extensions at once.

Hi @rclai we had a major update on the Meteor Accounts system and there are quite a few packages. Would you mind reviewing #16 ?

First off, thanks for this great package!

It would be great if it could also extend ground:db collections, which are pretty useful when building offline/mobile apps.

Hello, can you publish your last commit on atmosphere?

thanks

I'm not currently using your package, but I intend to in the future. Real nice work and definitely needed.

I just ran into another collection-behaviors, apparently quickly gaining traction. Realized it was a different one than the one you had on your list and thought you might want it on your TODO list, at the very least. I think the zimme package has autoform support which might be the upper hand for it right now.

Anyway, just an FYI ticket. :)