Any tips or tricks to avoid the common mistakes in your meteor projects?
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 
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:
Template.name.events({
'event #element': function(e){
$(e.currentTarget).val(); //e, is already JQ event!
e.currentTarget.value //=== $(e.currentTarget).val()
}
})
2 Likes
That mean we shouldn’t use e?
E is jq event, but e.target 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.