Negative - you’d want to import it wherever you use it. Like in the todos example app:
Exporting:
Importing:
Negative - you’d want to import it wherever you use it. Like in the todos example app:
Exporting:
Importing:
@sashko I’ve been doing this recently, but now I can’t access that collection on the browser console. Is that supposed to be the case? Also, it seems slower which makes me feel like minimongo isn’t being used.
It’s definitely not slower, it’s exactly identical to before.
If you want to access from the console I’d suggest putting a:
global.Lists = Lists
near where you export it.
Interesting. I must be doing something else wrong, because it seems to be making the round trip call to the server db before updating my view. Thanks!
Did you import your methods on the client?
Yes, and tested that both the client and the server methods are being called. Can’t figure out where the latency is coming from, but only started happening today after I moved to modules.
Why is there no mention of Astronomy in the guide?
See the discussion here: https://github.com/meteor/guide/issues/10
At the end of the day we felt we had to make a decision so we picked simple schema.
You could at least mention that there is an alternative, since Astronomy is in some peoples (plural since I think there are more than me ) view preferrable?
Yeah, we should mention it. I’m not sure what the best format is.
Is the Lists.deny
lines in the code above from Todos necessary? I thought all collections were deny by default as long as the insecure package is not installed.
Yes - if you read the text right next to it, it says that we add that so that nobody else can ever accidentally call allow
on that collection.
Thanks for clarifying, but I must be blind because I don’t see the “accidentally” quote.
Ohhhhhhhhhh wait I got totally confused. You were referring to the code snippet above from Todos. I was thinking of this section: http://guide.meteor.com/security.html#allow-deny
My mistake.
I have a ValidatedMethod that updates a collection document. Only the document author should be able to make updates. I tried to implement the editableBy helper from the todos example using dburles:collection-helpers as recommend in the Guide’s Collection helpers section.
const project = Projects.findOne({ _id: projectId });
if (!project.editableBy(this.userId)) {
throw new Meteor.Error('Projects.methods.edit.unauthorized', 'Only author can edit a project.');
}
It kept failing and then I re-read the Errors in method simulation section.
ValidatedMethod turns on undocumented option in Meteor to avoid calling the server-side implementation if the simulation throws an error.
I realized that the findOne in my code above would only work on the server. On the client it would always return null and throw and error which would block the server code. As a fix, I just wrapped the above code with !this.isSimulation
How does the Todos example work, because it doesn’t use isSimulation?
In Todos we publish the fields required to check the permissions to the client. But if you don’t, you’ll need to make the check server-only by using isSimulation.
Sorry, I’m having a hard time figuring out where the example makes those fields public. I tried adding publicFields but it had no effect.
Projects.publicFields = {
authorId: 1,
};
Which file actually makes it happen? Does it require and additional library like reywood:publish-composite?