From e4c81a6af5fa07ee5e9c51c131caaa9a4a662d68 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 18:43:57 -0600 Subject: [PATCH 1/9] Update article.md allows to -> allows us to --- 1-js/09-classes/07-mixins/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/09-classes/07-mixins/article.md b/1-js/09-classes/07-mixins/article.md index da230792..2e929e33 100644 --- a/1-js/09-classes/07-mixins/article.md +++ b/1-js/09-classes/07-mixins/article.md @@ -109,7 +109,7 @@ As `super` looks for parent methods in `[[HomeObject]].[[Prototype]]`, that mean Now let's make a mixin for real life. -An important feature of many browser objects (for instance) is that they can generate events. Events is a great way to "broadcast information" to anyone who wants it. So let's make a mixin that allows to easily add event-related functions to any class/object. +An important feature of many browser objects (for instance) is that they can generate events. Events is a great way to "broadcast information" to anyone who wants it. So let's make a mixin that allows us to easily add event-related functions to any class/object. - The mixin will provide a method `.trigger(name, [...data])` to "generate an event" when something important happens to it. The `name` argument is a name of the event, optionally followed by additional arguments with event data. - Also the method `.on(name, handler)` that adds `handler` function as the listener to events with the given name. It will be called when an event with the given `name` triggers, and get the arguments from `.trigger` call. From 5c11c5458c9dbc53c260ec95e594b8607e242693 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 19:03:36 -0600 Subject: [PATCH 2/9] Update article.md listen to -> listen for some punctuation, little words --- 1-js/09-classes/07-mixins/article.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/1-js/09-classes/07-mixins/article.md b/1-js/09-classes/07-mixins/article.md index da230792..cfee434f 100644 --- a/1-js/09-classes/07-mixins/article.md +++ b/1-js/09-classes/07-mixins/article.md @@ -113,9 +113,9 @@ An important feature of many browser objects (for instance) is that they can gen - The mixin will provide a method `.trigger(name, [...data])` to "generate an event" when something important happens to it. The `name` argument is a name of the event, optionally followed by additional arguments with event data. - Also the method `.on(name, handler)` that adds `handler` function as the listener to events with the given name. It will be called when an event with the given `name` triggers, and get the arguments from `.trigger` call. -- ...And the method `.off(name, handler)` that removes `handler` listener. +- ...And the method `.off(name, handler)` that removes the `handler` listener. -After adding the mixin, an object `user` will become able to generate an event `"login"` when the visitor logs in. And another object, say, `calendar` may want to listen to such events to load the calendar for the logged-in person. +After adding the mixin, an object `user` will be able to generate an event `"login"` when the visitor logs in. And another object, say, `calendar` may want to listen for such events to load the calendar for the logged-in person. Or, a `menu` can generate the event `"select"` when a menu item is selected, and other objects may assign handlers to react on that event. And so on. @@ -165,7 +165,7 @@ let eventMixin = { ``` -- `.on(eventName, handler)` -- assigns function `handler` to run when the event with that name happens. Technically, there's `_eventHandlers` property, that stores an array of handlers for each event name. So it just adds it to the list. +- `.on(eventName, handler)` -- assigns function `handler` to run when the event with that name occurs. Technically, there's an `_eventHandlers` property that stores an array of handlers for each event name, and it just adds it to the list. - `.off(eventName, handler)` -- removes the function from the handlers list. - `.trigger(eventName, ...args)` -- generates the event: all handlers from `_eventHandlers[eventName]` are called, with a list of arguments `...args`. @@ -193,7 +193,7 @@ menu.on("select", value => alert(`Value selected: ${value}`)); menu.choose("123"); ``` -Now if we'd like any code to react on menu selection, we can listen to it with `menu.on(...)`. +Now, if we'd like any code to react to a menu selection, we can listen for it with `menu.on(...)`. And `eventMixin` mixin makes it easy to add such behavior to as many classes as we'd like, without interfering with the inheritance chain. From cd1a23b9bd0bb23ff5156413a2c09dfe740ff879 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 19:14:36 -0600 Subject: [PATCH 3/9] Update article.md Summary -- adding 'adding' and 'happening'. --- 1-js/09-classes/07-mixins/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/09-classes/07-mixins/article.md b/1-js/09-classes/07-mixins/article.md index da230792..26152351 100644 --- a/1-js/09-classes/07-mixins/article.md +++ b/1-js/09-classes/07-mixins/article.md @@ -203,6 +203,6 @@ And `eventMixin` mixin makes it easy to add such behavior to as many classes as Some other languages allow multiple inheritance. JavaScript does not support multiple inheritance, but mixins can be implemented by copying methods into prototype. -We can use mixins as a way to augment a class by multiple behaviors, like event-handling as we have seen above. +We can use mixins as a way to augment a class by adding multiple behaviors, like event-handling as we have seen above. -Mixins may become a point of conflict if they accidentally overwrite existing class methods. So generally one should think well about the naming methods of a mixin, to minimize the probability of that. +Mixins may become a point of conflict if they accidentally overwrite existing class methods. So generally one should think well about the naming methods of a mixin, to minimize the probability of that happening. From 38ba46f0a0dabcef6c015ba1d2c72fe4c63e2ce7 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 19:39:00 -0600 Subject: [PATCH 4/9] Update article.md Added 'Oxford comma" (comma before 'and' at the end of a list). Not all consider it necessary, but I think it improves readability. --- 1-js/10-error-handling/1-try-catch/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/10-error-handling/1-try-catch/article.md b/1-js/10-error-handling/1-try-catch/article.md index f81bfc2b..9db33427 100644 --- a/1-js/10-error-handling/1-try-catch/article.md +++ b/1-js/10-error-handling/1-try-catch/article.md @@ -1,6 +1,6 @@ # Error handling, "try..catch" -No matter how great we are at programming, sometimes our scripts have errors. They may occur because of our mistakes, an unexpected user input, an erroneous server response and for a thousand other reasons. +No matter how great we are at programming, sometimes our scripts have errors. They may occur because of our mistakes, an unexpected user input, an erroneous server response, and for a thousand other reasons. Usually, a script "dies" (immediately stops) in case of an error, printing it to console. From 169fa7bafe1eae3f6f24b8d17ed8da229338cce5 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 19:44:47 -0600 Subject: [PATCH 5/9] Update article.md Add a comma, minor wording adjustments --- 1-js/10-error-handling/1-try-catch/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/10-error-handling/1-try-catch/article.md b/1-js/10-error-handling/1-try-catch/article.md index f81bfc2b..c684f137 100644 --- a/1-js/10-error-handling/1-try-catch/article.md +++ b/1-js/10-error-handling/1-try-catch/article.md @@ -25,8 +25,8 @@ try { It works like this: 1. First, the code in `try {...}` is executed. -2. If there were no errors, then `catch(err)` is ignored: the execution reaches the end of `try` and goes on skipping `catch`. -3. If an error occurs, then `try` execution is stopped, and the control flows to the beginning of `catch(err)`. The `err` variable (can use any name for it) contains an error object with details about what's happened. +2. If there were no errors, then `catch(err)` is ignored: the execution reaches the end of `try` and goes on, skipping `catch`. +3. If an error occurs, then `try` execution is stopped, and the control flows to the beginning of `catch(err)`. The `err` variable (can use any name for it) will contain an error object with details about what happened. ![](try-catch-flow.svg) From 91b17f3bf020205d70dc4969363b51654016cfb7 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Tue, 8 Oct 2019 20:32:15 -0600 Subject: [PATCH 6/9] Update article.md 'allow to' -> 'allow us to' optional comma --- 1-js/10-error-handling/1-try-catch/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/10-error-handling/1-try-catch/article.md b/1-js/10-error-handling/1-try-catch/article.md index f81bfc2b..cbd0b801 100644 --- a/1-js/10-error-handling/1-try-catch/article.md +++ b/1-js/10-error-handling/1-try-catch/article.md @@ -668,4 +668,4 @@ We can also generate our own errors using the `throw` operator. Technically, the *Rethrowing* is a very important pattern of error handling: a `catch` block usually expects and knows how to handle the particular error type, so it should rethrow errors it doesn't know. -Even if we don't have `try..catch`, most environments allow to setup a "global" error handler to catch errors that "fall out". In-browser that's `window.onerror`. +Even if we don't have `try..catch`, most environments allow us to setup a "global" error handler to catch errors that "fall out". In-browser, that's `window.onerror`. From 466f99568fad7b216cc887b126cc9af471a165a9 Mon Sep 17 00:00:00 2001 From: Chris Shyi Date: Thu, 10 Oct 2019 08:23:56 +0800 Subject: [PATCH 7/9] Fix minor grammatical error --- 1-js/11-async/03-promise-chaining/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/11-async/03-promise-chaining/article.md b/1-js/11-async/03-promise-chaining/article.md index e35c619e..eace803d 100644 --- a/1-js/11-async/03-promise-chaining/article.md +++ b/1-js/11-async/03-promise-chaining/article.md @@ -218,7 +218,7 @@ new Promise(resolve => resolve(1)) JavaScript checks the object returned by `.then` handler in the line `(*)`: if it has a callable method named `then`, then it calls that method providing native functions `resolve`, `reject` as arguments (similar to executor) and waits until one of them is called. In the example above `resolve(2)` is called after 1 second `(**)`. Then the result is passed further down the chain. -This feature allows to integrate custom objects with promise chains without having to inherit from `Promise`. +This feature allows us to integrate custom objects with promise chains without having to inherit from `Promise`. ```` From f66d4211aa9f0571f867e91a1dec27c82e9824c3 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Wed, 9 Oct 2019 20:38:00 -0600 Subject: [PATCH 8/9] Update article.md rephrasing --- 1-js/10-error-handling/2-custom-errors/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/10-error-handling/2-custom-errors/article.md b/1-js/10-error-handling/2-custom-errors/article.md index 2414ce7e..41ce7d88 100644 --- a/1-js/10-error-handling/2-custom-errors/article.md +++ b/1-js/10-error-handling/2-custom-errors/article.md @@ -23,7 +23,7 @@ Our function `readUser(json)` will not only read JSON, but check ("validate") th Our `ValidationError` class should inherit from the built-in `Error` class. -That class is built-in, here's it approximate code, for us to understand what we're extending: +That class is built-in, but here's its approximate code so we can understand what we're extending: ```js // The "pseudocode" for the built-in Error class defined by JavaScript itself From fe7ffe013017bbe8234d763e9ac2576be597efb8 Mon Sep 17 00:00:00 2001 From: paroche <46547072+paroche@users.noreply.github.com> Date: Wed, 9 Oct 2019 21:08:28 -0600 Subject: [PATCH 9/9] Update article.md if -> ifs Phrasing, punctuation. --- 1-js/10-error-handling/2-custom-errors/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/10-error-handling/2-custom-errors/article.md b/1-js/10-error-handling/2-custom-errors/article.md index 2414ce7e..08613dba 100644 --- a/1-js/10-error-handling/2-custom-errors/article.md +++ b/1-js/10-error-handling/2-custom-errors/article.md @@ -215,9 +215,9 @@ Now custom errors are much shorter, especially `ValidationError`, as we got rid The purpose of the function `readUser` in the code above is "to read the user data". There may occur different kinds of errors in the process. Right now we have `SyntaxError` and `ValidationError`, but in the future `readUser` function may grow and probably generate other kinds of errors. -The code which calls `readUser` should handle these errors. Right now it uses multiple `if` in the `catch` block, that check the class and handle known errors and rethrow the unknown ones. But if `readUser` function generates several kinds of errors -- then we should ask ourselves: do we really want to check for all error types one-by-one in every code that calls `readUser`? +The code which calls `readUser` should handle these errors. Right now it uses multiple `if`s in the `catch` block, that check the class and handle known errors and rethrow the unknown ones. But if the `readUser` function generates several kinds of errors, then we should ask ourselves: do we really want to check for all error types one-by-one in every code that calls `readUser`? -Often the answer is "No": the outer code wants to be "one level above all that". It wants to have some kind of "data reading error". Why exactly it happened -- is often irrelevant (the error message describes it). Or, even better if there is a way to get error details, but only if we need to. +Often the answer is "No": the outer code wants to be "one level above all that", it just wants to have some kind of "data reading error" -- why exactly it happened is often irrelevant (the error message describes it). Or, even better, it could have a way to get the error details, but only if we need to. So let's make a new class `ReadError` to represent such errors. If an error occurs inside `readUser`, we'll catch it there and generate `ReadError`. We'll also keep the reference to the original error in its `cause` property. Then the outer code will only have to check for `ReadError`.