Historical errata for Simplifying JavaScript

“To being” should be “To begin”

“pragrog.com” should probably be “pragporg.com”

In the TC39 box on the last line, it should read “or the Object spread” rather than “or they Object spread”

In setting up filters, filters2, and update, it seems that ‘const’ would be a better choice than ‘let’. Perhaps I am missing something?

Last paragraph, 4th sentence: change “… you can rely instead OF the language feature to limit scope.” to “… rely instead ON the …”.

Actually I prefer “… rely instead on language features …” since we are talking about let, const, modules, and I guess objects, too.

“code is easier to reason” -> “code is easier to reason about”

My apologies. The above typos for pages 25 and 26 were for a different book with a similar name. Please remove all these messages for me.

The JavaScript method for adding an item to the beginning of an array is written as being `array.shift()`, when it is actually `array.unshift()`. The `array.shift()` method removes the first item at the beginning of an array.

```
// Add to beginning.
const titles = [‘Moby Dick’, ‘White Teeth’];
titles.shift(‘The Conscious Mind’);
```

In the second code block on the page, the call should be to function yell instead of greet:
greet(‘Pankaj’);

on 2nd paragraph line 4:
to to reduce -> to reduce

In the second example from simple.js:
[…getCairoTrilogy] -> […getCairoTrilogy()]

(you should add parentheses)

the 1st line of the 2nd paragraph from the bottom:
the size array -> the size of array/the array size ?

The 1st line of the 2nd paragraph from the bottom:
means means -> means

The 3rd line of the 2nd paragraph:
they are really are that flexible

You should omit one of “are” s

The following statement strikes me as just a bit too stringent: “Though you can chain multiple ternary expressions together, you should avoid doing so.” Perhaps “you should avoid doing so” could be changed to “you should do so with care”.

I think chained ternaries can remain clear and expressive if constructed carefully. For example, the book proposes the following cleaned-up code as preferable over the indeed puzzling nested ternary:

if (title = 'manager') { return ['time', 'overtimeAuthorization', 'pay']; } if (title = ‘supervisor’) {
return [‘time’, ‘overtimeAuthorization’];
}
return [‘time’];

With some ample whitespace, this can be changed to a chained ternary which, in my eye, is readable and concise (well, when copy/pasted into a plain-text editor, at least):

return title = 'manager' ? ['time', 'overtimeAuthorization', 'pay'] : title = ‘supervisor’ ? [‘time’, ‘overtimeAuthorization’] :
/*else*/ ? [‘time’];

This structure reminds me of Clojure’s cond macro.

All in all, I like the message that ternaries can quickly get out of hand but I don’t believe chained ternaries need be avoided at all times.

Regarding #82416, my example code got mangled even more than I anticipated.

Please see o10c7gda on jsfiddle for a formatted example. Thanks!

you should update the output for:
anotherBook is changing it

const anotherBook = { title: ‘Another book’, year: 2016,
};
Object.assign(defaults, anotherBook);
// {
// author: ‘Joe Morgan’,
// title: ‘Simplifying JavaScript’,
// year: 2017,
// rating: null,
// }

what the hell is a ’Colbert" regarding truthiness. consider your non-american readers. p

In second sentence of second paragraph, change…

“Turns out, sorting by name a second time…”

… to…

“Turns out, sorting by years a second time…”

“affectively”[sic] should be “effectively”

“Deciding when to use proposed syntax is a matter of preference.”

You may wish to refer to the website caniuse.com where one can check the support of, say, spread operations.

“So if one value in an || check returns true, you get that truthy value and not true.”
perhaps reword to something like
“When a truthy value is found in an || check, you get that truthy value (which might be true or a non-zero number or a non-empty string”

Soon(?) you will be able to use the optional chaining operator (?.) and the nullish coalescing operator (??) for even more efficient short circuiting.

const assignedFunction = function() {
}

Finally! I’ve been holding my breath since Tip 3 in Chapter 1 for Joe to apply the benefits of block-scoping to function declarations and now that Tip is on the horizon — or is it an exercise left to the reader?

another site for checking feature availability is
kangax.github.io/compat-table/es2016plus/

‘wvoquine’ on page 144 vs. ‘wvoquie’ on pages 145 and 146. might be a typo.
V.v.O.Quine to wvoquine? Hobbes to Hobbs? Engels to Eagles?

Para. 5: “… but it isn’t accessible by JavaScript in the browser.” — please clarify.