Common JavaScript Gotchas
11–20 of 28 posts
Re: Common JavaScript Gotchas
#12 var i = 0;
var i = [];
No runtime error will be produced, and the script will continue normal execution.Re: Common JavaScript Gotchas
#13This can manifest itself in many ways. Usually in the form of a UI element being displayed more than once, but often more subtly such as a HTTP request being sent more than once. Often the bugs only manifest themselves after a certain sequence of actions, for example: click this UI element, check this radio box, then hit submit and watch the net tab.
It's so often the root cause of Javascript bugs that if I or somebody else on my team has a Javascript problem, I often start by asking myself if it looks like it could be this. Lately I have begun to wonder if there isn't some slight truth to that inflammatory "Callbacks are the new goto" story that was on here a couple of months ago [1].
Re: Common JavaScript Gotchas
#14The most common gotcha I encounter in Javascript has to do with callbacks. I see this problem all the time in my own code and that of my colleagues: callbacks that have been registered either more or less times than the author of the code expected. Usually more times. This can manifest itself in many ways. Usually in the form of a UI element being displayed more than once, but often more subtly such as a HTTP request…
I've yet to run into this problem before, and I'm an even split between JS / Ruby these days. Are you building on top of any particular libraries or frameworks? Could you give some examples of where you've encountered this?
Re: Common JavaScript Gotchas
#15One thing you didn't mention is strict mode. I think this rule is awesome for preventing issues like in your "bonus gotcha".
Re: Common JavaScript Gotchas
#16The most common gotcha I encounter in Javascript has to do with callbacks. I see this problem all the time in my own code and that of my colleagues: callbacks that have been registered either more or less times than the author of the code expected. Usually more times. This can manifest itself in many ways. Usually in the form of a UI element being displayed more than once, but often more subtly such as a HTTP request…
I see this problem all the time in my own code and that of my colleagues: callbacks that have been registered either more or less times than the author of the code expected. Usually more times. I've yet to run into this problem before, and I'm an even split between JS / Ruby these days. Are you building on top of any particular libraries or frameworks? Could you give some examples of where you've encountered this?
The other time was in a Rails app, where a script was added to a partial for a layout, and then added again later on (by a different developer) to the layout itself. That caused a particularly nasty bug since it used 'toggle', and thus the second callback negated the first.
Re: Common JavaScript Gotchas
#17Re: Common JavaScript Gotchas
#18Re: Common JavaScript Gotchas
#19This is not true, the var hoist the variable and scopes it to the function, but does not create it as a property of the function. A function is defined in its outer function scope, an it's properties will persist across calls.
function foo() {
var bar = 1;
foo.baz = 2;
}
foo();
foo.bar; // is undefined
foo.baz; // is 2
Adding properties to functions is useful for memoization, but is different than what the var statement does.Your summary of that section is a better explanation:
all variables are scoped to a function (which is itself an object), and where you declare those variables with var determines the function they are scoped to.
You might add, if you never declare the variable with var it is implicitly declared global.
Re: Common JavaScript Gotchas
#20Earlier quoted context omitted.
author here, it wasn't about hiding private variables. i was demonstrating using closures to avoid global namespace collisions which i think is generally a big problem for beginners.
i believe you mean using functions, not closures. your post doesn't seem to have the same misnomer, and simply explains lexical function scope. it doesn't seem to touch on the closure, while your parent comment does.