Common mistakes in Meteor?

Any tips or tricks to avoid the common mistakes in your meteor projects?

1 Like :wink:

1 Like

Was reading that already, thought there should be more tips?

Note to the community - I have added to that article a couple of times after initially posting it. I’m open to expanding it further if anyone has strong opinions/suggestions.

Something that got me recently is how mongo on the server, and mongo on the client sometimes act differently.

I had a brain fart and was trying to use $not in a query where I really needed to be using $ne.
Simplified, this was my query:

Collection.find({"email": email, "_id": {$not: user_id}})

On the server it was spitting out an error but when I tested the query in the browser console I didn’t get any errors and my query came back. My query on the server relied on variable data, and in the console I used fixed data. So I assumed that my variables were wrong … I spent a lot longer debugging the issue than I want to admit :stuck_out_tongue_closed_eyes:

The error message was quite clear - but I kept getting confused because it seemed to work in my console.
I will not fall for that again…

When I started to work with Meteor and learned it had reactivity, I thought one would use that as much as possible. But that just made my code messy, buggy and hard to read. Nowadays I use it as little as possible (more or less only for the UI), and that seems like a better approach.

One of the most overabused is imho this:{
'event #element': function(e){

$(e.currentTarget).val(); //e, is already JQ event!
e.currentTarget.value //=== $(e.currentTarget).val()


That mean we shouldn’t use e?

E is jq event, but is not a jQuery object.

@dweldon, I just published a new package, alanning:trace, that may be useful for the “Overworked Helpers” section. It logs client-side collection and template events to the browser console.

Source code can be found here.

Looks good. Thanks Adrian.