Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common JavaScript Gotchas

jblotus.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Common JavaScript Gotchas

#21

Post by jblotus »

damncabbage wrote: post #14
h2s wrote: post #13

The 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?

i've also run into this, usually through double event binding

Re: Common JavaScript Gotchas

#22

Post by martinced »

h2s wrote: post #13

The 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…

Multiple registration of callbacks and "too many similar events firing" (and even circular event firing : event A triggers event B, event B triggers event A) can all be solved by using event filtering no!?

I'm not saying it's a good thing to work around the issue by using event filtering, but events filtering is a great technique.

You can also use your event filtering to "fail fast" during development: detect a duplicated event called back? Throw an exception / make your application fail.

Re: Common JavaScript Gotchas

#23

Post by jblotus »

trip42 wrote: post #19

a basic explanation is that by preceding a variable declaration with var creates a property on the nearest containing function This 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…

thanks for the help

Re: Common JavaScript Gotchas

#24

Post by catshirt »

jblotus wrote: post #20
catshirt wrote: post #10

Earlier quoted context omitted.

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.

well, functions close over scope no matter what you call them.

not exactly. closures close over scope. functions alone simply create a new scope. these concepts are not synonymous.

if your function doesn't return another function, the references from that function are deallocated once the function has executed.

when your function returns a function (a "closure"), the inner function closes over the variables of the outer function, maintaining references to it's context as long as you maintain a reference to the closure.

Re: Common JavaScript Gotchas

#27

Post by jblotus »

jblotus wrote: post #26
dleibovic wrote: post #25

I thought php was also function scope, not block scope as the author claims...?

author here. function test() { echo $a } test(); in javascript, $a would be 1 but in PHP it is undefined and won't produce output,

after thinking about it for a while, I was misrepresenting what block scope actually was and removed those references in the post.

Re: Common JavaScript Gotchas

#28

Post by jblotus »

catshirt wrote: post #24
jblotus wrote: post #20

Earlier quoted context omitted.

well, functions close over scope no matter what you call them.

not exactly. closures close over scope. functions alone simply create a new scope. these concepts are not synonymous. if your function doesn't return another function, the references from that function are deallocated once the function has executed. when your function returns a function (a "closure"), the inner function closes over the variables of the outer function, maintaining references to it's context as long as…

ok i see your point. i conflated the terms function and closure in this case.
Post reply on HN