jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Fix typos

Browse source
This commit is contained in:
Alexey Pyltsyn 2019-05-01 16:51:27 +03:00
parent ca92aed539
commit feebafcc9e
5 changed files with 5 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

2
1-js/09-classes/04-private-protected-properties-methods/article.md
View file

@ -171,7 +171,7 @@ class CoffeeMachine {
new CoffeeMachine().setWaterAmount(100); new CoffeeMachine().setWaterAmount(100);
``` ```
That looks a bit longer, but functions are more flexible. They can accept multiple arguments (even if we don't need them right now). So, for the future, just in case we need to refactor something, functions are a safer choise. That looks a bit longer, but functions are more flexible. They can accept multiple arguments (even if we don't need them right now). So, for the future, just in case we need to refactor something, functions are a safer choice.
Surely, there's a tradeoff. On the other hand, get/set syntax is shorter, so ultimately there's no strict rule, it's up to you to decide. Surely, there's a tradeoff. On the other hand, get/set syntax is shorter, so ultimately there's no strict rule, it's up to you to decide.
```` ````

2
1-js/09-classes/06-instanceof/article.md
View file

@ -182,7 +182,7 @@ alert( {}.toString.call(user) ); // [object User]
For most environment-specific objects, there is such a property. Here are few browser specific examples: For most environment-specific objects, there is such a property. Here are few browser specific examples:
```js run ```js run
// toStringTag for the envinronment-specific object and class: // toStringTag for the environment-specific object and class:
alert( window[Symbol.toStringTag]); // window alert( window[Symbol.toStringTag]); // window
alert( XMLHttpRequest.prototype[Symbol.toStringTag] ); // XMLHttpRequest alert( XMLHttpRequest.prototype[Symbol.toStringTag] ); // XMLHttpRequest

2
1-js/10-error-handling/1-try-catch/article.md
View file

@ -68,7 +68,7 @@ Let's see more examples.
} catch(err) { } catch(err) {
alert(`Error has occured!`); // *!*(3) <--*/!* alert(`Error has occurred!`); // *!*(3) <--*/!*
} }

2
1-js/11-async/02-promise-basics/article.md
View file

@ -148,7 +148,7 @@ The second argument of `.then` is a function that:
1. runs when the Promise is rejected, and 1. runs when the Promise is rejected, and
2. receives the error. 2. receives the error.
For instance, here's a reaction to a successfuly resolved promise: For instance, here's a reaction to a successfully resolved promise:
```js run ```js run
let promise = new Promise(function(resolve, reject) { let promise = new Promise(function(resolve, reject) {

2
1-js/11-async/07-microtask-queue/article.md
View file

@ -167,7 +167,7 @@ setTimeout(() => promise.catch(err => alert('caught')));
window.addEventListener('unhandledrejection', event => alert(event.reason)); window.addEventListener('unhandledrejection', event => alert(event.reason));
``` ```
Now the unhandled rejction appears again. Why? Because `unhandledrejection` triggers when the microtask queue is complete. The engine examines promises and, if any of them is in "rejected" state, then the event is generated. Now the unhandled rejection appears again. Why? Because `unhandledrejection` triggers when the microtask queue is complete. The engine examines promises and, if any of them is in "rejected" state, then the event is generated.
In the example, the `.catch` added by `setTimeout` triggers too, of course it does, but later, after `unhandledrejection` has already occurred. In the example, the `.catch` added by `setTimeout` triggers too, of course it does, but later, after `unhandledrejection` has already occurred.