profile
viewpoint
Kyle Simpson getify Getify Solutions Austin, TX I teach JavaScript and I'd love to come help your team's developers. If that's interesting to you, please reach out to me getify@gmail.com.

getify/Functional-Light-JS 12485

Pragmatic, balanced FP in JavaScript. @FLJSBook on twitter.

getify/LABjs 2212

Loading And Blocking JavaScript: On-demand parallel loader for JavaScript with execution order dependencies

getify/asynquence 1603

Asynchronous flow control (promises, generators, observables, CSP, etc)

getify/CAF 804

Cancelable Async Flows (CAF)

getify/A-Tale-Of-Three-Lists 626

Comparing various async patterns for a single demo

getify/fasy 413

FP iterators that are both eager and asynchronous

getify/FPO 394

FP library for JavaScript. Supports named-argument style methods.

getify/JSON.minify 339

Simple minifier for JSON to remove comments and whitespace

getify/h5ive-DEPRECATED 336

**DEPRECATED** A collection of thin facade APIs wrapped around HTML5 JavaScript features.

getify/grips 288

Simple-logic templates

issue commentgetify/JSON.minify

Update Python readme

Is something wrong with the metadata for the python package? Why isn't import clean and simple?

trolologuy

comment created time in 5 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha b3c3f8f61de0f19f3669b17b3ca000c81469dd8a

scope and closures: ch7, finishing summary section

view details

push time in 9 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha abb7bbc33e2296c2c91f0b277f78374253800a89

scope and closures: ch7, completing first pass of 'why closures?' section

view details

push time in 10 hours

issue openedgetify/You-Dont-Know-JS

whatever

created time in 10 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 18f0812715a4d2352947c491680b188a3eb12afb

scope and closures: ch7, rewording for clarity

view details

push time in 14 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 8ba96c8ebf5ace181b8641d2d814b169d4da64af

scope and closures: ch7, rewording for clarity

view details

push time in 14 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 711618bfd685325b7d04b8b38d9e2481f357ef55

scope and closures: ch3, fixing figure-image URL

view details

push time in 15 hours

issue openedgetify/You-Dont-Know-JS

types & grammar: research trig math

https://macwright.org/2020/02/14/math-keeps-changing.html

created time in 19 hours

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 078d60ad05687e470e84cbf0c3e4a17564d5375b

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 6eb33d1ca06553e6c8710b4b6923c8a25a0b01a6

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 94995ac0cfa8571dec3b9d582452b1397e4b0662

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 83dad8afb0b076ee7c2ec789e6c2d714172dafd7

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 28737801c595eba936d30e87369659cdd972088c

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 8c32bcf7f7f1dee49bffcdfe0b56832c46acd211

scope and closures: ch7, added figures 4 and 5 to illustrate two mental models of closure, added 'an alternate perspective' section

view details

push time in a day

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 9bf28fac94f473bb7c8d650e155ca6e97cbb0fd9

scope and closures: broad sweep of readability tweaks, clarity revisions, and chapter renaming

view details

push time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha ef507a81558a919a0c043f180140363228ae78db

scope and closures: broad sweep of readability tweaks, clarity revisions, and chapter renaming

view details

push time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 8a76bda1ae51a1801d1ad2941eefe09f303db15c

get started: ch1, fixing mistake in reference to figure, closes #1601

view details

push time in 2 days

PR closed getify/You-Dont-Know-JS

fix reference to figure 1

Yes, I promise I've read the Contributions Guidelines and I already searched for this issue"

Edition: 2nd

Book Title: You Don't Know JS Yet: Get Started

Chapter: 1

Section Title: What's in an Interpretation?

Topic: is it [JS] compiled?

+2 -2

1 comment

1 changed file

devmi

pr closed time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha d2cf051bd9e5bbd36e09939afca5a6bb6fa5a27a

scope and closures: ch7, adding 'big picture' section

view details

push time in 2 days

pull request commentgetify/You-Dont-Know-JS

fix reference to figure 1

Good catch on the figure reference, but the book was finished with its writing, and indeed published, in January.

devmi

comment created time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha d6143a328c1c4b80f4f2b0f712ca5f65cbf54288

scope and closures: ch7, finishing 'closure lifecycle' section

view details

push time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 6d0f2a2a2a37e197322f2ea705b3816f843817d0

scope and closures: ch7, finishing 'closure lifecycle' section

view details

push time in 2 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha b583c629c93de5027f499757a3fa4997c048111b

scope and closures: ch7, adding to 'closure lifecycle' section

view details

push time in 3 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha fefaebaa15e25d14ed7e4097684f75dd1e9be222

scope and closures: ch7, adding several sections

view details

push time in 4 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 6014eafb5f3931b06c72f31840141d441fdc29da

scope and closures: ch7, starting 'closure lifecycle'

view details

push time in 5 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha cac7df8c0e7f31228e7b330a23c8919fa49148da

scope and closures: ch7, adding more to 'see the closure' section

view details

push time in 5 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 1fedcce326ec971593ee35c6f8712ee6d79de182

scope and closures: ch7, starting work on 'defined by observation' section

view details

push time in 6 days

issue closedgetify/You-Dont-Know-JS

Book's titles with broken links

Seems like is missing ".com"

closed time in 6 days

klaytonfaria

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha a317044ad3b0bb3550049493f39937569afdcb18

scope and closures: revisions per editorial comments, closes #1584

view details

push time in 6 days

issue closedgetify/You-Dont-Know-JS

Editorial Review, Scope & Closures, Chapter 6

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:

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.

Blocked over

Nice conclusion.

closed time in 6 days

simonstl

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha be5ec64948d842da454662521ddf54b5943eddb5

scope and closures: big reorg (splitting ch3 into three chapters, moving ch5 to ch7 and ch6 to ch8), addressing editorial revisions, closes #1578

view details

push time in 6 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha f99ac58f665cdb510baa29330f3cfabd09bd1af8

scope and closures: big reorg (splitting ch3 into three chapters, moving ch5 to ch7 and ch6 to ch8), addressing editorial revisions, closes #1578

view details

push time in 6 days

issue closedgetify/You-Dont-Know-JS

Editorial Review, Scope & Closures, Chapter 3

Editorial review, not a searchable issue.

Edition: (1st or 2nd) 2nd

Book Title: Scope & Closures

Chapter: 3

General

I'm sorry for taking so long on this, but this is by far the most daunting chapter I've reviewed so far. I've been daunted enough to think that maybe it's a sign that this chapter has too moving parts, and think it needs at least some reorganization and probably some splitting out into smaller (still dense) chapters. If you can stand to break it into more digestible chunks, I'd suggest something like:

  • Nested Scope
  • Global Scope and its Discontents
  • Variable Visibility (Starts with "When can I use a variable?")
  • Block Scope (already a separate chapter)

Each of those seems like a field learners can master and know that they've mastered, pause, and move forward.

Intro

This is where readers need to really get down to code, over and over. I'd suggest re-writing the intro to make sure readers know that things are changing, and to welcome them to a much more intense exploration. The intro largely talks about the previous chapter. I'd refocus that on "You've seen X, but now it's time for Y." Gird them for the challenges ahead, and rev them up for it.

I really like the Tip and "This is one of those chapters that really hammers home just how much we all don't know about scope."

Nested Scopes, Revisited

This is mostly fine, but the colors reference when the colors were in the previous chapter and not here is tricky. Since the reference continues into the chapter, maybe re-include the figure?

"Lookup" Is (Mostly) Conceptual

I think a lot of this section depends on the jump from "the information as we have it in this one JS file" to "the information when interpreted in the full context of multiple running JS files."

While I like leaving the marbles "uncolored" as a metaphor, I also want something more. What process will the marble sorting machine use to assign those colors? It's kind of like a pachinko machine, the gates of which are the other JS files coming in. (Maybe this all moves to the Global Scope section? That has the explanation I want.)

I'd integrate the Note pointing to Chapter 2's Lookup Failures into the text as the outcome of that process not working. Also, I'd make that explicitly "Chapter 2's Lookup Failures section". I went looking for a different Chapter 2.

Shadowing

This is a much more comfortable and concrete section. The only thing I'd suggest is starting out by acknowledging the somewhat mysterious headline rather than introducing the word shadowing a page later.

Global Unshadowing Trick

I'd move the Warning information to the first paragraph - make clear to readers that this is something that they should know, but avoid using. I suspect it will entice readers to focus more closely on forbidden knowledge, and will definitely make sure that they don't miss the warning.

I would also take a second look at the paragraph starting with "Notice the window.studentName reference?" You haven't really talked about window or its being effectively global scope in this context, so I'd start with something less puzzling.

Copying is Not Shadowing

This seems strong, except that it makes me long for languages where variables are immutable.

Illegal Shadowing

All seems happy here.

Function Name Scope

Your explanations are solid, but this is one of those corners where I really want a "why is it different?" Is it just history, or are there reasons these differences in behavior are a good idea?

Arrow Functions

I'm really happy to see this story told here - not just the how, but the complications of the "simpler" syntax. At the very least, this gives readers the context they need to figure out where something went weird.

Why Global Scope?

Even if you don't break this chapter into smaller chapters, I'd combine this section with the following "Where Exactly is this Global Scope?" section and its many subsections. The overall topic is Global Scope, and the Why and the Where are parts of that conversation.

The details of the Why section seem to leap into the Where rather than the Why. That seems like another reason to combine it with the Where, but I'd love a few paragraphs on why having global scope at all is a good (or dangerous) idea. It's certainly a contested space....

The information on the effective context of modules and bundled code is excellent. Granted, I want to retreat to my minimal-shared-context-functional-programming world at the end of it, but that's my default.

Where Exactly is This Global Scope?

I'd strongly recommend combining this and its many subsections with the "Why Global Scope?" section to create a single Global Scope section (or preferably chapter).

Browser Window

All happy.

Shadowing Revisited

I think I'd retitle this "Shadowing Global Variables", mostly so people can find it quickly. I'd also lead with the warning rather than conclude with it.

What's in a Name?

The headline is fun, but it took me a moment to figure out what it referred to. Maybe "What's in a window.name?"

Are there more corner cases like this one? If so, a list of the corners would be great, though a full exploration is likely too much.

Web Workers

I think I'd put this section earlier in the list, because it's a simpler (and increasingly more important) exception. Web Workers don't share the main global scope. This is a good thing, because... but they also have their own effective global scope.

Developer Tools Console/REPL

My only concern here is whether the details of this vary from console to console and REPL. I don't think it needs in-depth exploration, but are these things consistent across environments?

ES Modules

I'm not quite sure what this means:

They are not added to any global scope object, nor are they added to any accessible "module-global" object.

Is that "accessible from outside of the module"? They seem accessible from the inside. Is this just normal-ish module encapsulation, or is something more exciting happening?

Node

The Warning ("Node treats every single .js file that it loads...") is the most exciting and probably important part of the section. I think you were aiming to maining continuity with the prior ES modules conversation, but this shift in scope handling is more important. Note it, and then return to the modules conversation.

GlobalThis

Wow. Cross-environment convenience, I guess, but it makes me shudder. Your coverage is fine.

When Can I Use a Variable?

I would open the variable hoisting discussion by noting that historically, it's been a feature that developers stumbled on when their code broke for what seemed like mysterious reasons. Surprise! Once you know about hoisting, debugging is much easier, as is structuring code to avoid (or use) it. (Function hoisting seems much less surprising, I guess because of OOP style in multiple languages.) Maybe frame this whole section and its sub-sections as a series of surprises?

Yet Another Metaphor

I'm wondering if it makes sense to emphasize that "hoisting" is a broken metaphor from the outset and then explain the brokenness, rather than walking through common explanations and wandering into it. Emphasize that people need to know the term "hoisting" to be able to communicate with other developers, but not get caught up in this metaphor.

Re-declaration

Yet more surprises! I'm happy for the clarification on let/var re-declaration errors at the end.

Constants?

This all looks good. I hope you'll return to the "error thrown when re-assigning to studentName is a Type Error, not a Syntax Error" in the Types book.

Loops

Is the scope inside the loop a case of block scope (next chapter?). It seems to me like it should be, and yet...

The explanation for const with the traditional for loop and its rewriting makes me very happy.

Uninitialized

Could you put Temporal Dead Zone into the section header somehow? The name itself seems like to draw readers, and its presence would give a hint at the beginning of what's to come later in the section.

"Many have claimed that" feels weak and oddly political. I don't think you need to say that. Instead something more direct like "TDZ can make it look like let and const do not hoist, but this is inaccurate." Make it less about the debate and more about the code.

Scope Closed

I love the headline, but wish the chapter was broken into smaller ones.

closed time in 6 days

simonstl

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 825c63bcf672dfe026a69c7b91d5fae7cfe7d99b

scope and closures: big reorg (splitting ch3 into three chapters, moving ch5 to ch7 and ch6 to ch8), addressing editorial revisions, closes #1578

view details

push time in 6 days

PR closed getify/You-Dont-Know-JS

generator functions syntax correction

the "" should be stick to function keyword not the function name; I already searched for this issue, reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function

+2 -2

1 comment

1 changed file

Mhmdrza

pr closed time in 9 days

pull request commentgetify/You-Dont-Know-JS

generator functions syntax correction

The * can be placed either next to function or next to the function's name, with or without spaces on either side of it. It's a stylistic preference. I prefer to put it next to the function name.

Mhmdrza

comment created time in 9 days

startedkrasimir/octomments

started time in 12 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 8cfb44814baeadb83a8db24b0adc851e1dcf41c2

scope and closures: ch2, replacing fig3

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha def4d01fac5c4a87fa8bfd0f28b567e8c92ec0b0

scope and closures: ch2, replacing fig3

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 82fb09ec48888f2f7f982716ecd2a200f1bebe2b

scope and closures: ch2, replacing fig3

view details

push time in 13 days

issue closedgetify/You-Dont-Know-JS

Ch1: don't use terms like "JS6" or "ES8"

In chapter 1, What's With That Name, there is this note: Don't use terms like "JS6" or "ES8" to refer to the language. Some do, but those terms only serve to perpetuate confusion. "ES20xx" or just "JS" are what you should stick to.

However the rest of the text uses exclusively ES6 instead of ES2015 in direct contradiction to this note. Suggest either editing the note or changing references of ES6 to ES2015.

closed time in 13 days

TJZXG

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha ea0e4bc7e973ee150a2a6c0ead3148b3ac441bb9

scope and closures: ch2, revisions per feedback, closes #1570

view details

push time in 13 days

issue closedgetify/You-Dont-Know-JS

Editorial Review, Scope & Closures, Chapter 2

Editorial review, not a searchable issue.

Edition: (1st or 2nd) 2nd

Book Title: Scope & Closures

Chapter: 2

Intro

I think this one works. I'm glad you explicitly explain that you'll be using metaphors, as there's a category of readers who... take offense at metaphors? Just want code all the time? They might still skip this.

Buckets and bubbles and marbles

As I started reading, I wondered where the bubbles were. Maybe re-sort this to marbles and buckets and bubbles, oh my!?

I LOVE figure 1. It helps! However, I have a few related concerns. I think the numbers help deal with issues that might arise for color-blind readers. However, the contrast levels are tricky. On screen, the contrast levels work for me, but when I print it out on a black and white laser printer, the distinctions among the bubbles are not very clear. Since you'll have a print edition, and print on demand is rarely sharper than a laser printer, I'd encourage you to increase the contrast. Bubble number 2 might be the best place to do that, darkening it slightly.

The NOTE answered a lot of my "why is this missing?" questions but still left me wanting more. Which is fine - that's another book.

I wonder if it make sense to refer to the RED(1) bubble rather than just the RED bubble (and similar) throughout. Also, buckets and bubbles are kind of interchangeable here, but I think it works in part because the words are similar.

A Conversation Among Friends

I like the explicit change of metaphor and the very different perspective. I also like the script model for the conversations. All it needs is stage directions (exit stage right) and it'll be the first steps toward a JS opera. Or not. It's all good.

The Lookup Failures section doesn't have any of the script model, but I'm thinking it (with some stage directions in which Scope Manager concocts a bad idea) might work especially well here for the accidental global variable case. You could contrast the strict and not strict models easily.

Building on Metaphors

This section (and metaphor) doesn't seem as developed or as necessary as the others, but it's reinforcing, so still a good thing to have.

Continue the Conversation

All good, except "solid on" feels a bit odd to me.

closed time in 13 days

simonstl

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 3f0c81d5d54610bc8e67a79cae3c14ec51ca6aa7

scope and closures: ch2, improving color contrast of fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha d31d2203cbce55406fc9caa32fd0ffaa338a0c69

scope and closures: ch2, improving color contrast of fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 74b8e31e997125342af930cbaded5dfbd5c7f6e8

scope and closures: ch2, improving color contrast of fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 9d7d219a56b9b847927488b6edd01049188b47cf

scope and closures: ch2, improving color contrast of fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha de1bcc27be7fcccba5883d236fcb2d731fcf3518

scope and closures: ch2, improving color contrast of fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha c64a17264cbe55571a004fcfe8f849faec290082

scope and closures: ch1, adding figure 1

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 8e16b72064f986741c44726aebd7aad62e69d2eb

scope and closures: ch1, adding figure 1

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha c97ab73d3ef12b06f5cc43ce00f0788194a42a45

scope and closures: ch1, adding figure 1

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 884de4fb39798f40305581f241077cd5a9040e7b

scope and closures: ch2, moving fig2 -> fig3 and fig1 -> fig2

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 0240a43933bbdb6ef73f7972e8f01f552ae03ac0

scope and closures: ch3, readability revisions and clarifications

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 9cda18f7d6022fd082beaa5664de6344d7327481

scope and closures: ch1, tweaking intro's tone

view details

push time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 1ee575e09c80b106c273f535f2318833d012ce2b

scope and closures: ch1, revisions per editorial feedback, closes #1569

view details

push time in 13 days

issue closedgetify/You-Dont-Know-JS

Editorial Review, Scope & Closures, Chapter 1

Editorial review, not a searchable issue.

Edition: (1st or 2nd) 2nd

Book Title: Scope & Closures

Chapter: 1

Intro

The opening of the first chapter is the most important point for welcoming readers to the book and encouraging them to stay. "One key foundation" is static and dull. Please rewrite this section to be more welcoming and compelling. Something more like:

Managing state is the central challenge most programs face. As you decide how to structure your variables and manage what goes in them, you build the foundations for everything else you do. Working with the grain of JavaScript, understanding how JavaScript manages variables, will make the rest of your programming easier.

Master JavaScript's underlying structures for working with variables, understand how your program's variables are organized and accessed by the JS engine, and you'll be able to create programs that are easier to debug, maintain, and extend. Discipline becomes much easier when you understand why things work.

JS has a well-defined set of rules for managing variables, called scope. The first step to understanding scope is to study how the JS engine processes and executes a program.

About This Book

I think this section was made redundant by adding the preface. I'd drop the headline "About this Book" and move the contents of the section to the end of the preface. (At first I thought to combine them with Compiling Code or the Intro, but that breaks up the topic flow more than I would like.)

Compiling Code

I worry that the first paragraph may baffle readers who don't already understand the difference between interpretation and compilation. I also think that many readers who do understand the difference would benefit from a brief refresh, and readers who won't benefit will forgive.

The Note in the middle of the numbered list is odd. Given that you already have multi-paragraph entries, I'd make it a regular paragraph, maybe a paragraph in parentheses. (Notes are really fancy parentheticals...)

Required: Two Phases

I really like the demonstration by breaking things here. It's a great way to show something weird, and people puzzle over these kinds of things regularly. (I, um, have.)

There are a couple of forward references, for hoisting and TDZ, to Chapter 3. I don't mind forward references, but these could use a bit more polish. The paragraph and Warning about TDZ in particular feel clunky because the reference happens repeatedly.

Compiler Speak

I'm glad to have an example to work with for a while, but I'm not sure as a reader what to do with a section that's a few short paragraphs, a block of code, and a Note as long as the paragraphs put together. Usually a section should accomplish a discrete task, and I'm not sure what that task is here.

Maybe add an intro paragraph explaining the exercise you're doing in the larger section? I'm also thinking that the Note makes sense as a regular paragraph, especially since the next subsections are Targets and Sources.

Targets (and Sources)

I like the way you play with this, inviting readers to find the targets for themselves. I tend to create a worked-through example and then a challenge, but your approach is better here.

Cheating: Run-Time Scope Modifications

I wouldn't personally call these cheating. Referring back to your earlier discussions of how JavaScript features are there for a reason, these two seem there for very clear reasons. I'd consider taking that approach while still warning of the consequences. Also, are these the only places you discuss eval and with? It seems likely. If so, they might be worth somewhat broader discussion, including of the dangers of eval more generally. I know they do get used in the wild at times...

Lexical Scope

I can't sort out what the first sentence is trying to tell me.

For a language whose scope is determined at compile time, its scope model is called "lexical scope".

Is that "Because JS's scope is determined at compile time, its scope model is called 'lexical scope'." Or is JS unusual in applying this term?

In a lot of ways this feels like a wrap-up and summary of the chapter, but I first encountered without realizing that it was the end, so it was kind of strange to review while expecting new. Maybe flag that with something like "let's put together JS's scope story"?

closed time in 13 days

simonstl

issue openedgetify/You-Dont-Know-JS

sync & async: research event loop

https://www.youtube.com/watch?v=cCOL7MC4Pl0

created time in 13 days

issue openedlukehaas/RunJS

"Check for Updates..." is broken

I get the following error (on windows) when I try to check for updates, even in the latest updated RunJS.

Annotation 2020-02-04 095351

The HTTP 404 error is against this URL: https://github.com/lukehaas/RunJS/releases/download/v1.8.0/latest.yml

However, checking the release assets on github here, there is no such file, which is the source of the 404. The assets folder has "latest-mac.yml" and "latest-linux.yml", but no "latest.yml" (or "latest-windows.yml").

created time in 13 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha a525d848dcaad792dc2eac527ed7e751fdcc3089

get started: ch2, fixing minor typo

view details

push time in 16 days

PR closed getify/You-Dont-Know-JS

Merge

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+118 -31726

0 comment

94 changed files

JessicaS97

pr closed time in 18 days

PR closed getify/You-Dont-Know-JS

Merge pull request #1 from getify/master

Master

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+0 -0

0 comment

0 changed file

JessicaS97

pr closed time in 18 days

issue commentgetify/eslint-plugin-proper-arrows

Include delegations under trivial functions

Like I said, I could see a case for another category of allowable arrow functions (tho it would have to stay defaulted to disallowing, to prevent breaking changes).

My concern is, where do we draw the line?

x => f(x) is pretty reasonable, but x => foo.bar(x * 2 + 3,y,...whatever) is not, IMO, deserving of any other label than "complex", which is to say that you should just not use this plugin if you like allowing those.

If we can come up with a reasonable and tight definition of what's narrowly allowed in this class of arrow function, I'm open to adding it.

clar-cmp

comment created time in 20 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 37ae6313f8cce52db143317e0854a7844f24a385

get started: README, adding book cover image

view details

push time in 21 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 64243b46a1e557bbc937b19c355d9f27d9f87d72

get started: README, adding book cover image

view details

push time in 21 days

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 613f1e0f64698f948dbd9220cc682b0bb825c295

get started: ch1 and ch2, fixing 2 typos

view details

push time in 21 days

issue commentgetify/eslint-plugin-proper-arrows

Extend definition of trivial to include comparisons

I replied in the other thread to explain my thinking around "trivial". The more I think about it the more x => x <= y is absolutely not "trivial" IMO, for the reasons stated there.

clar-cmp

comment created time in 21 days

issue commentgetify/eslint-plugin-proper-arrows

Include delegations under trivial functions

The term "trivial" refers to visual and cognitive triviality... aka "readability".

For example, () => x is much more visually simple, unambiguous, and ultimately readable at a glance than () => new foo.bar(y * 3).

I was just indicating that I could see () => fn(x) as something someone may want to allow, though () => new foo.bar.baz.bam.whatever(x + 1,w * 2,y / z) to me is not the same. But neither of those is as readable-trivial as () => x, IMO.

clar-cmp

comment created time in 21 days

issue closedgetify/eslint-plugin-proper-arrows

False positive on object destructuring in arrow function parameters

The following will report a params count error:

({foo, bar, baz, bat, bongo }) => {/* a function that handles all those 'named' parameters */}

While the following won't

function namedParams({foo, bar, baz, bat, bongo }) {/* a function that handles all those 'named' parameters */}

This might be intentional, as it seems weird to use the pattern in an anonymous function, but the lint error should be more exact.

closed time in 25 days

davidwkeith

issue closedgetify/eslint-plugin-proper-arrows

Add `id` to the default allowed list of short params

Reasoning:

  • Usually clear from context which ID is being referenced.
    • Rule could be be interpreted to say that a name like userId is preferred, but inside a function handling user logic that might be redundant.
  • people use the term ID rather than Identifier when talking
  • Even if the type of ID is unclear, it is still clear what an ID is. That sort of code review seems beyond the scope of a linter.

closed time in 25 days

davidwkeith

issue closedgetify/eslint-plugin-proper-arrows

Errors when disabling the rules in Create React App

I am getting the following error when I add the rules to a CRA app and try and disable existing errors:

Line 1:1:  Definition for rule '@getify/proper-arrows/return' was not found  @getify/proper-arrows/return

Search for the keywords to learn more about each error.

The eslint-disable directive is as follows:

/* eslint-disable @getify/proper-arrows/return */

closed time in 25 days

davidwkeith

issue commentgetify/eslint-plugin-proper-arrows

some "where" rules do not notify warning/error on text editors

So, to restate, is the issue that Babel has changed its representation (in an AST sense) of export const a = .. from version 5 to 6, so that my plugin no longer recognizes those?

cirocfc

comment created time in 25 days

issue commentgetify/eslint-plugin-proper-arrows

Extend definition of trivial to include comparisons

These feel very "not trivial" to me, not in the complexity sense but in the readability sense, especially the comparison operators like >, >=, <, and <=, given how visually similar those are to the => arrow designator.

clar-cmp

comment created time in 25 days

issue commentgetify/eslint-plugin-proper-arrows

Include delegations under trivial functions

I'm not sure I see these as "trivial", though I could see a case to be made for there to be a separate category for them.

clar-cmp

comment created time in 25 days

issue commentgetify/You-Dont-Know-JS

Ch1: don't use terms like "JS6" or "ES8"

The note is about current references to the language name, not historical ones.

Up until only a few months before ES2015 shipped, it had been referred to, even officially, as ES6. The attempted change by TC39 at that late a moment didn't stick, as far as I'm concerned. Some of us had even published books with "ES6" in the title, so... ES6 is the name, as was ES5 and ES3.

Starting with the next revision, though, the naming change took effect, meaning from ES2016 forward, that's the name. Some kept trying to say "ES7" or "ES8", but those are inaccurate.

TJZXG

comment created time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha a6bdf0862676b7e25b72a3d25bbc4c740cab22ee

get started: syncing tweaks from typesetting

view details

push time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 44089954010472723c96179235da832e11ea4748

scope and closures: README, adding name/link for Foreword, closes #1585

view details

push time in a month

PR closed getify/You-Dont-Know-JS

Fix typo - from 'scope' to 'source'.

'scope' should be 'source' in the phrase 'target vs. scope'.

Please type "I already searched for this issue": I already searched for this issue.

Edition: (pull requests not accepted for previous editions) 2

Book Title: Scopes and Closures

Chapter: Chapter 2: Understanding Lexical Scope

Section Title: Nested Scope

Topic: Lookup Failures

+1 -1

0 comment

1 changed file

vishrut

pr closed time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 2d132fcac8b75d457badae8a71a18d5d4b170365

scope and closures: fixing mistake, closes #1572

view details

push time in a month

PR closed getify/You-Dont-Know-JS

Update ch2.md

I don't know if this is a correct way to put it, but I'm sure it was a bit hard for me to understand what you wrote

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+1 -1

2 comments

1 changed file

Aegario

pr closed time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 4329ab2440019cc9a1e4af3ea961a1d315fdba44

scope and closures: tweaking wording for clarity, closes #1590

view details

push time in a month

push eventgetify/You-Dont-Know-JS

WillClayworth

commit sha 1f165d86477fecc7adace68e1f1550fa6af5031f

Update ch4.md (#1591) Fix typo from PLOP to POLP

view details

push time in a month

PR merged getify/You-Dont-Know-JS

Update ch4.md

Fix typo from PLOP to POLP

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+1 -1

0 comment

1 changed file

WillClayworth

pr closed time in a month

pull request commentgetify/You-Dont-Know-JS

multiple pages: fix typos

Thanks, I got these in.

schneiderl

comment created time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 7066f86788d4af9d1d4bd8445cef8ee4a91c56b5

fixing some typos, per #1593

view details

push time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha e0354d3315feafee9583d1400647d35ed17f345e

fixing some typos, per #1593

view details

push time in a month

pull request commentgetify/You-Dont-Know-JS

Update chapter 2

This difference is on purpose, to illustrate that a child class can define its own constructor with a different kind of signature from the parent constructor.

Lafaa

comment created time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 1f54fc4e0df8714296e56748df1948ca5057386d

get started: fixing figure images

view details

Kyle Simpson

commit sha 78c49f38e2de0a7ebd654e5196bd6b4f1d3e513d

get started: renaming 'resources' folder to 'images'

view details

push time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha a4539038f303512fb7c5252d32fa37e98f8b15e5

get started: tweaks from typesetting

view details

push time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha d9106d8ccd9fbba4df6e5c034bbaf535257139f7

get started: tweaks from typesetting

view details

push time in a month

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha b5ebd0da3db39b02466284aab89365c67b0e028e

get started: tweaks from typesetting

view details

push time in a month

issue commentgetify/CAF

Can't use with create-react-app

Just released v9.0.0. Hopefully this is resolved now! Please let me know.

vincerubinetti

comment created time in a month

push eventgetify/CAF

Kyle Simpson

commit sha 3f33c5ca27217ea460903d7febc3587029ef3517

fixing package.json so CAF works with webpack, updating dev dependency, closes #12 closes #13

view details

push time in a month

issue closedgetify/CAF

Can't use with create-react-app

Hello, I tagged you on Twitter about this a few days ago, but I figured it was okay to open an issue here. I feel like create-react-app is used by enough people (80k stars on GitHub) that it's worth looking into this issue.

How to reproduce the error

Make a new create-react-app app:

npx create-react-app my-test-app
cd my-test-app

Install caf:

npm install caf

Include caf in any /src file -- say App.js -- as specified in the readme:

var CAF = require("caf");

Save the changes and run the app:

npm start

Observe the following error, when running locally:

Error: Cannot find module '/dist/abortcontroller-polyfill-only.js'

Or observe the following error when running on CodeSandbox:

ModuleNotFoundError
Could not find module in path: 'caf/dist/abortcontroller-polyfill-only.js' relative to '/node_modules/caf/index.js'

CodeSandbox for convenient testing

https://codesandbox.io/s/frosty-tree-cwe5z


I'll post comments here as I try to figure out how to fix the issue.

closed time in a month

vincerubinetti

PR closed getify/CAF

Fix the browser path in package.json for webpack

This is a fix for a seemingly wrong path that was added to the package.json with the most recent pull request (8.0.1) https://github.com/getify/CAF/pull/10

I've also included the version number upgrade (8.0.2)

+2 -2

1 comment

1 changed file

stefan-kern

pr closed time in a month

issue commentgetify/CAF

Can't use with create-react-app

So it's more canonical/correct/expected to point it at src/caf.src.js, it seems. Agreed that this is the best fix here?

vincerubinetti

comment created time in a month

more