I don’t know what’s wrong, as the syntax I wrote looks correct from what I’ve read. But I get the error none the less. I’m still on Meteor 1.3, and ecmascript 0.4.8 if that matters.
.
Again, I get no errors with this syntax:
import ( test1, test2, test3, doSomethingCool } from '../../imports/server/module1.js
only the wildcard:
import * as importedModule1 from '../../imports/server/module1.js
.
I’ve never seen your syntax used to import everything, only to import the default variable or function.
Just to move this along, for now I added everything to a Docs object like so:
import { THE_USER } from './users'
let userId = '';
if (THE_USER) userId = THE_USER;
const query = { userId: userId }; // On startup THE_USER is undefined
// On startup the findOne returns undefined
let record = collection_name.findOne(query);
if (!record) record = {};
let {
first: test1,
second: test2,
third: test3
} = record;
export const doSomethingCool = () => { ... }
const Docs = {};
Docs.First = {
test1
}
Docs.Second = {
test2
}
Docs.Third = {
test3
}
Docs.Functions = {
doSomethingCool
}
export default Docs;
I can now do the following
//
import Docs from '../../imports/server/module1.js'
Docs.First.test2 // => "some string'
// But this DOES NOT work
Docs.doSomethingCool() //=> TypeError: Object [object Object] has no method
Probably depends on your use case, but if you wanted to minimize the imports and keep things like your adminFields from hitting the client, you could do something like:
const Docs = new Mongo.Collection('docs');
Docs.publicFields = {
// only public fields
};
const adminFields = {
// all the fields
};
export const PublicDocs = Docs;
export const AdminDocs = _.extend(Docs, { adminFields });
What I’m wondering about is, if you’re actually sending down the Docs to your client instead of what we usually do, which is just to publish then subscribe on the client. Instead you seem not be subscribing on the client, just loading the module and retreiving the data? Is this reactive without a subscription?
No, we still use the pub/sub model, but have just found it handy to attach props to the collection object that are used all the time. Things like the fields we limit, the keys we pass into omnisearch queries, keys that we use to trigger certain functionality, etc.