2

Background:

So I'm creating an admin package for meteor 1.4.2 with react so I can learn how to do that sort of thing. The admin package will just be able to update user defined collections (insert, delete, modify).

I have this file in my application under imports/api/posts.js:

// imports/api/posts.js
import { Meteor } from 'meteor/meteor';
import { Mongo } from 'meteor/mongo';

export const Posts = new Mongo.Collection('posts');

if (Meteor.isServer) {
   Meteor.publish('posts', function postsPublication() {
      return Posts.find();
   });
}

I can easily access this file within my application using for example import { Posts } from '../imports/api/posts.js';.

Problem:

How can I access the same Posts collection from within the admin package so I can insert a new item, remove one, etc?

Also, I saw this post earlier about a similar thing, but does that mean packages such as yogiben:admin don't work with the module system either?

Community
  • 1
  • 1
FergusThePlant
  • 65
  • 8

2 Answers2

3

The key to understanding this is realising that some meteor packages are libraries, and some are extensions of the (Meteor) framework as defined here.

yogiben:admin is an extension of the Meteor framework, in that it needs to be able to find code that you have written (your collections) in order to work correctly.

How you enable this is up to you. Previously collections were globally defined, so that they would be (automatically/eagerly) imported, and generally outside the /client or /server directories so they would be accessible on both the client and server.

Now you have the choice - define your collections outside the /imports directory, and they will still be eagerly imported, or import them where your admin framework requires them. As a third way you could require they be attached to the (server side) global object e.g. as a dict (i.e. global.myCollections = {'posts': Posts}), and (in browser) the window object (with window.myCollections = {'posts': Posts}).

yogiben:admin's example starter repo keeps everything outside /imports, however I suspect this would still work fine if you just kept the collection definitions outside /imports, moving the rest of the code to the currently recommended project structure.

Community
  • 1
  • 1
JeremyK
  • 3,240
  • 1
  • 11
  • 24
  • Good answer, thanks for the link to libraries vs. frameworks - I didn't really think about that for meteor packages. I think the cleanest solution out of what you suggested is defining the collections outside of `/imports` - I'll try that. – FergusThePlant Nov 09 '16 at 01:15
0

I do not think that Meteor has a way to get all collections defined in an app internally.

To achieve that you could override the Mongo.Collection method to keep a reference to every created collections.

const _oldCollection = Mongo.Collection;

Mongo.Collection = function(name, options) {
  const c = new _oldCollection(name, options);

  Meteor.myCollections[name] = c;

  return c;
};

Then use it as:

// define new collection
new Mongo.Collection('questions');

// retrieve collection
const c = Meteor.myCollections['questions'];

Make sure the code used to override Mongo.Collection loaded before you use it to define new collections.

kkkkkkk
  • 7,628
  • 2
  • 18
  • 31