impatient-js
impatient-js copied to clipboard
Chapter: Syntax
I know this is WIP but couldn't help notice these things. Apologies if some of these are things you're already working on or this is not the type of feedback you're looking for. Also, kudos to this innovative idea of collecting feedback.
5.1.1
- JS doesn't have
assert
as a construct. NodeJS brings it in as a module and there's aconsole.assert
that's not so widely known/used/supported.
5.1.2
- JS doesn't support
import
unless the file ends with.mjs
. Might be worthwhile to point that out.
5.3.2
- Comma after
undefined
whereas rest of the section doesn't use comma as a separator - Typo at the beginning:
Is is also a good ...
5.5.1
-
An anonymous function expression looks similar, but is an expression and works differently:
An example as to how might be helpful. Right now (at least to me), it leaves more questions unanswered.
-
If you give the function expression a name, it now has the same syntax as a function declaration:
Begs the question - so what? Again, an example as to how or why it should matter might be helpful here.
-
Disambiguation will have to answer the following question: What happens if I use a named function expression as a statement?
Not sure if this is meant for the audience or more of a todo for you or something else.
5.5.4
- I feel like a lot is going on here.
Prior to ES6, an IIFE (pronounced “iffy”) was a popular way of simulating block scoping.
This assumes that a reader already is familiar with what "simulating block scoping" in this conetxt means (the classic for loop example). Not sure if your targetting beginners as an audience but if you are, then this section can use some expansion. It's a lot to digest with IIFE, eval, assert all thrown in in the mix.
5.5.6
- Typo:
parens
5.7.2
- Example 4:
- How does
const stringify = function (x)...
becomeconst func = function (x) {...
during execution? - Where do the
assert
statements come from?
- How does
5.9.1. Switching on strict mode
- Talks about how to switch it on in legacy mode but doesn't mention that JS modules have strict mode on, automatically.
Hi, Would be nice if sections (“bullet points”) stand out from the actual code, my eye can’t focus on something specific:
I think styling (not necessarily numbering) “declaring variables”, “control flow statement” in a similar way as per example below, will increase legibility of the section:
Typo in section 6.5.3. Disambiguation where within
The ambiguities are only a problem is statement context: [...]
is should be replaced with in
Since expressions can be used wherever statements are allowed - but not vice versa - , and since both can be said to do something ('branch execution', 'perform computation',...) would it be accurate to simply say that expressions are statements that return a value?
In section 6.1.2 I think the intention of
export function isTextFilePath(filePath){ return str.endsWith('.txt'); }
is to be
export function isTextFilePath(filePath){ return filePath.endsWith('.txt'); }
@mrchief Thanks for the feedback! I especially appreciate content-related comments (what is difficult to understand etc.). In the next release, the typos you reported will be fixed and the chapter on syntax will be simpler (I removed quite a bit of unnecessary content).
Regarding your other items:
-
import
: In browsers,import
doesn’t care about filename extensions, only about content types. I’ll switch to (and will explain).mjs
, once Node.js supports it without a flag. - “paren” is a common abbreviation for “parenthesis”, but I have removed it, just in case.
@ivansvlv I’m now slightly indenting the code, which should help.
@codesurgeon Thanks! This will be fixed in the next release.
@wlycdgr You can, because the issue is that JavaScript makes a distinction where there shouldn’t be one.
@cramhead Indeed, thanks! Fixed in next release.
6.1.2 Modules
// Import whole module as namespace object `path`
import * as path from 'path';
Is 'path'
a bit surprising here (as only module file paths were mentioned before)?
6.1.1 Basic syntax
// Operators for numbers
assert.equal(3 + 4, 7);
assert.equal(5 - 1, 4);
assert.equal(3 * 4, 12);
assert.equal(9 / 3, 3);
The Remainder operator is missing here.
Hi,
In [Quizzes]Syntax (advanced) question no. 8 explanation it says (https://exploringjs.com/impatient-js/quiz/syntax-advanced.html)
const arr = Object.keys({a: 1, b: 2, c: 3}) [1].forEach(x => console.log(arr[x]))
*With a semicolon at the end of the first line, the output is indeed 'b'.
This statement seems incorrect to me.
@OnlyDeLtA Why? Easy to check: run this code (with a semicolon) in a browser console or the Node.js REPL.
@rauschma Thanks for the reply. My bad, I misread arr[x] as x on second line. nothing wrong with the given explanation.