Why are collections not imported or defined in the register-api / api.js file ? Where are they imported and defined?

[Kamin12]

I am having trouble with collections being defined on my application. I have been following the meteor guide. It says that the api.js file imports collections, publications, and methods.

However, on this example app, there is no api.js file, there is a register-api.js file. In this file, only methods and publications are imported and defined. How should collections be defined and imported into this file? Why are they said to be imported and defined in the meteor guide in the file api.js, but in the example app it is named register-api.js, and there are no collections imported or defined in that file?

[alanning]

(I know this is an older issue but figured I'd address it so it can be closed.)

The collections are defined in the API files and imported where needed.

In this file, the collection is exported for use by other code: export const Lists = new ListsCollection('lists');

On the client the flow is like this:

client/main.js
  /imports/startup/client/index.js
    /imports/startup/client/routes.js
      /imports/ui/layouts/app-body.js
        /imports/api/lists/lists.js

[evolross]

Ah. I had this same exact question. It's confusing because for methods and publications there's the register-api.js file. So I take it this is basically copying those method and publication definitions into Meteor.call and Meteor.publish (because you never import a publication or Meteor method... you simply call it through the Meteor object).

Where the collections simply get imported by whatever needs to use them which inherently runs what is defined on the collection object (e.g. schemas, collection hooks, allow/deny, etc.). It still seems weird though. Like it would need something to run what's in the Collection files. But I also see that any functions defined off the collection object in a collection.js file also need to be exported and imported to be used. So it all makes sense.

[alanning]

Looking through it again, I can see why it's a bit more confusing than normal.

At the core, there's two environments, client-side browser and server-side nodejs. Both environments need certain code loaded (imported) before it can be used.

Meteor's client-server communication is pretty neat, it takes care of a lot of things for us under the hood. As you mentioned, on the client the Meteor object gives us access to the call and subscribe functions which simply pass a message to the server requesting something be run. On the client, we don't need to import the server-side code that is actually executed unless we want to take advantage of Meteor's optimistic concurrency in which case we'd need to import the Meteor method definitions (or provide an alternative).

On the server, we have to tell Meteor what code should be executed when the client sends those messages and that server-side code needs to import whatever collection files it uses.

So the /imports/api/lists/lists.js file is imported in both environments.

Here's the flow on server:

server/main.js
  /imports/startup/server/index.js
    /imports/startup/server/register-api.js
      /imports/api/lists/server/publications.js
        /imports/api/lists/lists.js

      /imports/api/lists/methods.js
        /imports/api/lists/lists.js

https://github.com/meteor/todos/blob/master/imports/api/lists/lists.js