The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
| Version |
Location |
Description |
Submitted by |
Date submitted |
| ePub |
End of Prefac |
http://youdontknowjs.com/ link doesn't work
|
Yisroel Lazerson |
Mar 07, 2017 |
| Printed |
Page 10
Lexical Scope discussion |
Nested scope resolution. I may be confused. I think of nested scopes as being more hierarchical, as opposed to the diagram of a building with all the scopes available for inspection.
The building diagram seems to indicate that if you can't find a variable definition within your immediate scope, the Engine will just inspect all scopes within the global scope. That doesn't seem right. Aren't there limits to where the Engine can look, in order to resolve a variable (or other object) reference?
Even so, I'm really glad I got your book. I refer back to it more than most all other hard copies I've got.
Regards,
Tom
|
Tom Finegan |
Jul 18, 2017 |
| Printed |
Page 36
The code example near the end of the page |
The below code sample rightly produces a ReferenceError:
{
console.log(bar); //ReferenceError!
let bar = 2;
}
However, the statement, "Such declarations will not observably "exist" in the block until the declaration statement" is not accurate. If it was accurate, then below code should display 5 and shouldn't produce an error, but it does (because the global variable is hidden):
let bar = 5 //Declared in global scope
{
console.log(bar); //ReferenceError!
let bar = 2;
}
In both cases, the full error is ReferenceError: Cannot access 'bar' before initialization. This means the declaration is still observable (that's how it hid the global bar). It's just that as part of the declaration, the value is uninitialized when we use let/const, but its initialized to undefined when we use var. "let/const will not provide a default initialization." seems more accurate. I understand at this point, the book has still not addressed the initialization concept; maybe this section has to be moved or has to indicate this is because of initialization.
|
Andrew Nessin Rajamani |
Mar 08, 2022 |
| Printed |
Page 50
Code example |
The only coding example on this page is this:
function foo () {
var a = 2;
function baz () {
console.log ( a );
}
bar ( baz );
}
function bar (fn) {
fn ();
}
The following statement should be added to the bottom of the code:
foo ();
|
David Wilkinson |
Jan 07, 2019 |
| PDF |
Page 52
Top of the page, in 1st paragraph |
The inner function actually has a name "timer", it's not anonymous. I think "...that anonymous function still has closure over that scope." should read "...that inner timer function still has closure over that scope."
|
Timea Bálint |
Apr 17, 2019 |
| PDF |
Page 217
6th paragraph / 2nd to last paragraph |
"My counter-argument would be: if you’re favoring consistency, be consistent with var instead of const; let is definitely more like var than let."
The last clause in that sentence should read, "let is definitely more like var than const."
The author is pointing out that the behavior of 'let' is more similar to the behavior of 'var' than to that of 'const'. However, there is a typographical mistake in the last word of the sentence, and the declarator 'let' is mistakenly used instead of 'const".
|
Clark |
Jun 14, 2021 |