This chapter is just as dense as the previous one, but feels more comfortable. Its tighter focus makes it both shorter and easier to follow, though I have one question below about whether Hiding in Plain Function Scope is in the right place.
Intro
If you split the previous chapter, the intro here will need revision. The first sentence is nicely welcoming, though, recognizing the work that readers have already done and preparing them to do more.
Least Exposure
Nicely done! I wish I'd had this when I was trying to shift from Applesoft BASIC to, well, anything else. My only question here is whether this belongs earlier in the book. It absolutely applies here, but I think it provides a great "why" for pretty much all scope issues as well.
Hiding in Plain Function Scope
The factorial/cache example is well-chosen. It's something where the reasons to hide the cache are clear, and accidental collisions are even likely in a library of similar code. The code and the text reinforce each other well.
My only concern is organizational. Why is this section opening a chapter on block scope? It feels like it belongs with the section on function expressions, and I don't see an explicit connection to the later block scope sections.
Invoking Function Expressions Immediately
This is a great explanation of many angles of IIFE scope that have irked me. I am guessing that you will be covering questions about IIFEs and program structure elsewhere?
Function Boundaries
The conclusion of this is a nice segue to block scope, but still reminds that I've spent much of the chapter in function scope rather than block scope. Otherwise, yes - I'm delighted that you explain why return can become mysterious in this context.
You raise one issue that makes me want to know more:
Non-arrow function IIFEs also change the binding of a this keyword.
What does that look like? I suspect it might be a small section of its own.
Scoping with Blocks
This section feels to me like the core of the chapter. I remember attempting to use blocks (or, as I thought of them, "stuff within curly braces") to isolate and debug JavaScript long ago, to no result whatsoever. At least it didn't break things. I'm happy to see that they are now useful that way, at least with let and const.
The Note on cases where curly braces don't create scope feels more important than a Note. (Too many readers skip notes and even warnings.) I'd integrate that with the text, or even create a small section on what creates (and doesn't create) a block.
Then follow that with examples of block scope at work, then discuss var and let, and then at the end of var/let, get to the questions of TDZs and let/const declarations in the middle of a block. (The last part is currently in a Warning earlier on, but I think deserves a brief expansion and example after the var/let discussion.)
var and let
I love this coverage, and that you've (always) been willing to acknowledge the controversy around it. In particular:
var has always, from the earliest days of JS, signaled "variable that belongs to a whole function". As we asserted in "Lexical Scope" (Chapter 1), var attaches to the nearest enclosing function scope, no matter where it appears.
is just right. It's an explicit notice that a variable's scope is bound to a function.
When to use let?
I wonder if this should be where to use let? It's not so much a question of whether to use let but where best to put it.
I'm a little confused by pre-ES6 "the next-best thing". It sounds like it uses var as a flag to indicate to other programmers (and yourself) that "you should pay attention to scope on this thing", while not actually changing JavaScript's opinion on the variable scope. Is that right?
Everything here looks good, except that the part starting with"ES2019 (recently, at the time of writing) changed catch clauses" doesn't feel like it's about scope until you reach the Note at the end. However, I think it's fine - just probably worth making sure it gets mentioned in greater detail elsewhere.
Functions Declarations In Blocks (FiB)
I think that's supposed to be "Function" (no s) in the headline, but...
whoa! This section is weirdly scary. Everything up to here made sense, if complicated sense, but then "[JavaScript] is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come."
This section worries me, but for reasons of JavaScript, not your writing.
Editorial review, not a searchable issue.
Edition: (1st or 2nd) 2nd
Book Title: Scope & Closures
Chapter: 6
General
This chapter is just as dense as the previous one, but feels more comfortable. Its tighter focus makes it both shorter and easier to follow, though I have one question below about whether Hiding in Plain Function Scope is in the right place.
Intro
If you split the previous chapter, the intro here will need revision. The first sentence is nicely welcoming, though, recognizing the work that readers have already done and preparing them to do more.
Least Exposure
Nicely done! I wish I'd had this when I was trying to shift from Applesoft BASIC to, well, anything else. My only question here is whether this belongs earlier in the book. It absolutely applies here, but I think it provides a great "why" for pretty much all scope issues as well.
Hiding in Plain Function Scope
The factorial/cache example is well-chosen. It's something where the reasons to hide the cache are clear, and accidental collisions are even likely in a library of similar code. The code and the text reinforce each other well.
My only concern is organizational. Why is this section opening a chapter on block scope? It feels like it belongs with the section on function expressions, and I don't see an explicit connection to the later block scope sections.
Invoking Function Expressions Immediately
This is a great explanation of many angles of IIFE scope that have irked me. I am guessing that you will be covering questions about IIFEs and program structure elsewhere?
Function Boundaries
The conclusion of this is a nice segue to block scope, but still reminds that I've spent much of the chapter in function scope rather than block scope. Otherwise, yes - I'm delighted that you explain why return can become mysterious in this context.
You raise one issue that makes me want to know more:
What does that look like? I suspect it might be a small section of its own.
Scoping with Blocks
This section feels to me like the core of the chapter. I remember attempting to use blocks (or, as I thought of them, "stuff within curly braces") to isolate and debug JavaScript long ago, to no result whatsoever. At least it didn't break things. I'm happy to see that they are now useful that way, at least with let and const.
The Note on cases where curly braces don't create scope feels more important than a Note. (Too many readers skip notes and even warnings.) I'd integrate that with the text, or even create a small section on what creates (and doesn't create) a block.
Then follow that with examples of block scope at work, then discuss var and let, and then at the end of var/let, get to the questions of TDZs and let/const declarations in the middle of a block. (The last part is currently in a Warning earlier on, but I think deserves a brief expansion and example after the var/let discussion.)
var and let
I love this coverage, and that you've (always) been willing to acknowledge the controversy around it. In particular:
is just right. It's an explicit notice that a variable's scope is bound to a function.
When to use let?
I wonder if this should be where to use let? It's not so much a question of whether to use let but where best to put it.
I'm a little confused by pre-ES6 "the next-best thing". It sounds like it uses var as a flag to indicate to other programmers (and yourself) that "you should pay attention to scope on this thing", while not actually changing JavaScript's opinion on the variable scope. Is that right?
Everything here looks good, except that the part starting with"ES2019 (recently, at the time of writing) changed
catchclauses" doesn't feel like it's about scope until you reach the Note at the end. However, I think it's fine - just probably worth making sure it gets mentioned in greater detail elsewhere.Functions Declarations In Blocks (FiB)
I think that's supposed to be "Function" (no s) in the headline, but...
whoa! This section is weirdly scary. Everything up to here made sense, if complicated sense, but then "[JavaScript] is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come."
This section worries me, but for reasons of JavaScript, not your writing.
Blocked over
Nice conclusion.