Merge branch 'master' of github.com:javascript-tutorial/en.javascript.info into sync-9cb33f40

Author: root

1-js/02-first-steps/03-strict-mode/article.md

@@ -53,9 +53,17 @@ For the future, when you use a browser console to test features, please note tha
 
 Sometimes, when `use strict` makes a difference, you'll get incorrect results.
 
-Even if we press `key:Shift+Enter` to input multiple lines, and put `use strict` on top, it doesn't work. That's because of how the console executes the code internally.
+You can try to press `key:Shift+Enter` to input multiple lines, and put `use strict` on top, like this:
 
-The reliable way to ensure `use strict` would be to input the code into console like this:
+```js
+'use strict'; <Shift+Enter for a newline>
+//  ...your code
+<Enter to run>
+```
+
+It works in most browsers, namely Firefox and Chrome.
+
+If it doesn't, the most reliable way to ensure `use strict` would be to input the code into console like this:
 
 ```js
 (function() {

1-js/03-code-quality/04-ninja-code/article.md

@@ -137,7 +137,7 @@ Instead, reuse existing names. Just write new values into them.
 
 In a function try to use only variables passed as parameters.
 
-That would make it really hard to identify what's exactly in the variable *now*. And also where it comes from. A person with weak intuition would have to analyze the code line-by-line and track the changes through every code branch.
+That would make it really hard to identify what's exactly in the variable *now*. And also where it comes from. The purpose is to develop the intuition and memory of a person reading the code. A person with weak intuition would have to analyze the code line-by-line and track the changes through every code branch.
 
 **An advanced variant of the approach is to covertly (!) replace the value with something alike in the middle of a loop or a function.**
 
@@ -155,7 +155,7 @@ function ninjaFunction(elem) {
 
 A fellow programmer who wants to work with `elem` in the second half of the function will be surprised... Only during the debugging, after examining the code they will find out that they're working with a clone!
 
-Seen in code regularly. Deadly effective even against an experienced ninja. 
+Seen in code regularly. Deadly effective even against an experienced ninja.
 
 ## Underscores for fun
 
@@ -169,8 +169,7 @@ A smart ninja puts underscores at one spot of code and evades them at other plac
 
 Let everyone see how magnificent your entities are! Names like `superElement`, `megaFrame` and `niceItem` will definitely enlighten a reader.
 
-Indeed, from one hand, something is written: `super..`, `mega..`, `nice..` But from the other hand -- that brings no details. A reader may decide to look for a hidden meaning and meditate for an hour or two.
-
+Indeed, from one hand, something is written: `super..`, `mega..`, `nice..` But from the other hand -- that brings no details. A reader may decide to look for a hidden meaning and meditate for an hour or two of their paid working time.
 
 
 ## Overlap outer variables
@@ -180,7 +179,7 @@ When in the light, can't see anything in the darkness.<br>
 When in the darkness, can see everything in the light.
 ```
 
-Use same names for variables inside and outside a function. As simple. No efforts required.
+Use same names for variables inside and outside a function. As simple. No efforts to invent new names.
 
 ```js
 let *!*user*/!* = authenticateUser();

1-js/06-advanced-functions/11-currying-partials/article.md

@@ -170,7 +170,7 @@ To understand the benefits we definitely need a worthy real-life example.
 
 Advanced currying allows the function to be both callable normally and partially.
 
-For instance, we have the logging function `log(date, importance, message)` that formats and outputs the information. In real projects such functions also have many other useful features like sending logs over the network:
+For instance, we have the logging function `log(date, importance, message)` that formats and outputs the information. In real projects such functions also have many other useful features like sending logs over the network, here we just use `alert`:
 
 ```js
 function log(date, importance, message) {
@@ -184,34 +184,29 @@ Let's curry it!
 log = _.curry(log);
 ```
 
-After that `log` still works the normal way:
-
-```js
-log(new Date(), "DEBUG", "some debug");
-```
-
-...But also can be called in the curried form:
+After that `log` work both the normal way and in the curried form:
 
 ```js
+log(new Date(), "DEBUG", "some debug"); // log(a,b,c)
 log(new Date())("DEBUG")("some debug"); // log(a)(b)(c)
 ```
 
-Let's get a convenience function for today's logs:
+Now we can easily make a convenience function for current logs:
 
 ```js
-// todayLog will be the partial of log with fixed first argument
-let todayLog = log(new Date());
+// currentLog will be the partial of log with fixed first argument
+let currentLog = log(new Date());
 
 // use it
-todayLog("INFO", "message"); // [HH:mm] INFO message
+currentLog("INFO", "message"); // [HH:mm] INFO message
 ```
 
-And now a convenience function for today's debug messages:
+And here's a convenience function for current debug messages:
 
 ```js
-let todayDebug = todayLog("DEBUG");
+let todayDebug = currentLog("DEBUG");
 
-todayDebug("message"); // [HH:mm] DEBUG message
+currentLog("message"); // [HH:mm] DEBUG message
 ```
 
 So:

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

@@ -278,7 +278,7 @@ The good thing is: a `.then` handler is guaranteed to run whether the promise ta
 
 Next, let's see more practical examples of how promises can help us to write asynchronous code.
 
-## Example: loadScript
+## Example: loadScript [#loadscript]
 
 We've got the `loadScript` function for loading a script from the previous chapter.
 

1-js/11-async/03-promise-chaining/article.md

@@ -146,7 +146,7 @@ Returning promises allows us to build chains of asynchronous actions.
 
 ## Example: loadScript
 
-Let's use this feature with `loadScript` to load scripts one by one, in sequence:
+Let's use this feature with the promisified `loadScript`, defined in the [previous chapter](/promise-basics#loadscript), to load scripts one by one, in sequence:
 
 ```js run
 loadScript("/article/promise-chaining/one.js")
@@ -305,7 +305,7 @@ fetch('/article/promise-chaining/user.json')
   });
 ```
 
-The code works, see comments about the details, but it should be quite self-descriptive. Although, there's a potential problem in it, a typical error of those who begin to use promises.
+The code works, see comments about the details. Although, there's a potential problem in it, a typical error of those who begin to use promises.
 
 Look at the line `(*)`: how can we do something *after* the avatar has finished showing and gets removed? For instance, we'd like to show a form for editing that user or something else. As of now, there's no way.
 

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

@@ -124,7 +124,6 @@ Naturally, `promise` shows up first, because `setTimeout` macrotask awaits in th
 
 As a logical consequence, macrotasks are handled only when promises give the engine a "free time". So if we have a chain of promise handlers that don't wait for anything, execute right one after another, then a `setTimeout` (or a user action handler) can never run in-between them.
 
-
 ## Unhandled rejection
 
 Remember "unhandled rejection" event from the chapter <info:promise-error-handling>?

1-js/12-generators-iterators/2-async-iterators-generators/article.md

@@ -3,13 +3,13 @@
 
 Asynchronous iterators allow to iterate over data that comes asynchronously, on-demand.
 
-For instance, when we download something chunk-by-chunk, or just expect events to come asynchronously and would like to iterate over them -- async iterators and generators may come in handy. Let's see a simple example first, to grasp the syntax, and then review a real-life use case.
+For instance, when we download something chunk-by-chunk, and expect data fragments to come asynchronously and would like to iterate over them -- async iterators and generators may come in handy. Let's see a simple example first, to grasp the syntax, and then review a real-life use case.
 
 ## Async iterators
 
-Asynchronous iterators are totally similar to regular iterators, with a few syntactic differences.
+Asynchronous iterators are similar to regular iterators, with a few syntactic differences.
 
-"Regular" iterable object from the chapter <info:iterable> look like this:
+"Regular" iterable object, as described in the chapter <info:iterable>, look like this:
 
 ```js run
 let range = {
@@ -101,7 +101,7 @@ let range = {
 })()
 ```
 
-As we can see, the components are similar to regular iterators:
+As we can see, the structure is similar to regular iterators:
 
 1. To make an object asynchronously iterable, it must have a method `Symbol.asyncIterator` `(1)`.
 2. It must return the object with `next()` method returning a promise `(2)`.
@@ -117,22 +117,22 @@ Here's a small cheatsheet:
 | to loop, use                          | `for..of`         | `for await..of` |
 
 
-````warn header="The spread operator doesn't work asynchronously"
+````warn header="The spread operator ...  doesn't work asynchronously"
 Features that require regular, synchronous iterators, don't work with asynchronous ones.
 
 For instance, a spread operator won't work:
 ```js
 alert( [...range] ); // Error, no Symbol.iterator
 ```
 
-That's natural, as it expects to find `Symbol.iterator`, same as `for..of` without `await`.
+That's natural, as it expects to find `Symbol.iterator`, same as `for..of` without `await`. Not `Symbol.asyncIterator`.
 ````
 
 ## Async generators
 
-JavaScript also provides generators, that are also iterable.
+As we already know, JavaScript also supprots generators, and they are iterable.
 
-Let's recall a sequence generator from the chapter [](info:generators). It generates a sequence of values from `start` to `end` (could be anything else):
+Let's recall a sequence generator from the chapter [](info:generators). It generates a sequence of values from `start` to `end`:
 
 ```js run
 function* generateSequence(start, end) {
@@ -147,7 +147,7 @@ for(let value of generateSequence(1, 5)) {
 ```
 
 
-Normally, we can't use `await` in generators. All values must come synchronously: there's no place for delay in `for..of`.
+Normally, we can't use `await` in generators. All values must come synchronously: there's no place for delay in `for..of`, it's a synchronous construct.
 
 But what if we need to use `await` in the generator body? To perform network requests, for instance.
 
@@ -184,15 +184,15 @@ It's indeed very simple. We add the `async` keyword, and the generator now can u
 
 Technically, another the difference of an async generator is that its `generator.next()` method is now asynchronous also, it returns promises.
 
-Instead of `result = generator.next()` for a regular, non-async generator, values can be obtained like this:
+In a regular generator we'd use `result = generator.next()` to get values. In an async generator, we should add `await`, like this:
 
 ```js
 result = await generator.next(); // result = {value: ..., done: true/false}
 ```
 
 ## Iterables via async generators
 
-When we'd like to make an object iterable, we should add `Symbol.iterator` to it.
+As we already know, to make an object iterable, we should add `Symbol.iterator` to it.
 
 ```js
 let range = {
@@ -270,7 +270,7 @@ The pattern is very common, it's not about users, but just about anything. For i
 - It responds with a JSON of 30 commits, and also provides a link to the next page in the `Link` header.
 - Then we can use that link for the next request, to get more commits, and so on.
 
-What we'd like to have is an iterable source of commits, so that we could use it like this:
+What we'd like to have is a simpler API: an iterable object with commits, so that we could go over them like this:
 
 ```js
 let repo = 'javascript-tutorial/en.javascript.info'; // GitHub repository to get commits from
@@ -332,7 +332,7 @@ An example of use (shows commit authors in console):
 })();
 ```
 
-That's just what we wanted. The internal pagination mechanics is invisible from the outside. For us it's just an async generator that returns commits.
+That's just what we wanted. The internal mechanics of paginated requests is invisible from the outside. For us it's just an async generator that returns commits.
 
 ## Summary
 
@@ -356,6 +356,6 @@ Syntax differences between async and regular generators:
 
 In web-development we often meet streams of data, when it flows chunk-by-chunk. For instance, downloading or uploading a big file.
 
-We could use async generators to process such data, but there's also another API called Streams, that may be more convenient, as it provides special interfaces to transform the data and to pass it from one stream to another (e.g. download from one place and immediately send elsewhere). But they are also more complex.
+We can use async generators to process such data, but it's worth to mention that there's also another API called Streams, that provides special interfaces to transform the data and to pass it from one stream to another (e.g. download from one place and immediately send elsewhere). 
 
 Streams API not a part of JavaScript language standard. Streams and async generators complement each other, both are great ways to handle async data flows.

2-ui/1-document/08-styles-and-classes/article.md

@@ -66,10 +66,10 @@ So we can operate both on the full class string using `className` or on individu
 Methods of `classList`:
 
 - `elem.classList.add/remove("class")` -- adds/removes the class.
-- `elem.classList.toggle("class")` -- if the class exists, then removes it, otherwise adds it.
+- `elem.classList.toggle("class")` -- adds the class if it doesn't exist, otherwise removes it.
 - `elem.classList.contains("class")` -- returns `true/false`, checks for the given class.
 
-Besides that, `classList` is iterable, so we can list all classes like this:
+Besides, `classList` is iterable, so we can list all classes with `for..of`, like this:
 
 ```html run
 <body class="main page">
@@ -147,7 +147,7 @@ To set the full style as a string, there's a special property `style.cssText`:
 </script>
 ```
 
-We rarely use it, because such assignment removes all existing styles: it does not add, but replaces them. May occasionally delete something needed. But still can be done for new elements when we know we won't delete something important.
+This property is rarely used, because such assignment removes all existing styles: it does not add, but replaces them. May occasionally delete something needed. But we can safely use it for new elements, when we know we won't delete an existing style.
 
 The same can be accomplished by setting an attribute: `div.setAttribute('style', 'color: red...')`.
 ````

2-ui/2-events/03-event-delegation/4-behavior-tooltip/task.md

@@ -18,7 +18,7 @@ Should work like this:
 
 [iframe src="solution" height=200 border=1]
 
-In this task we assume that all elements with `data-tooltip` have only text inside. No nested tags.
+In this task we assume that all elements with `data-tooltip` have only text inside. No nested tags (yet).
 
 Details:
 
@@ -33,4 +33,4 @@ Please use event delegation: set up two handlers on `document` to track all "ove
 
 After the behavior is implemented, even people unfamiliar with JavaScript can add annotated elements.
 
-P.S. To keep things natural and simple: only one tooltip may show up at a time.
+P.S. Only one tooltip may show up at a time.

2-ui/2-events/03-event-delegation/article.md

@@ -182,7 +182,7 @@ The pattern has two parts:
 
 ### Counter
 
-For instance, here the attribute `data-counter` adds a behavior: "increase on click" to buttons:
+For instance, here the attribute `data-counter` adds a behavior: "increase value on click" to buttons:
 
 ```html run autorun height=60
 Counter: <input type="button" value="1" data-counter>

2-ui/5-loading/02-script-async-defer/article.md

@@ -188,8 +188,11 @@ But there are also essential differences between them:
 | `defer` | *Document order* (as they go in the document). |  Execute after the document is loaded and parsed (they wait if needed), right before `DOMContentLoaded`. |
 
 ```warn header="Page without scripts should be usable"
-Please note that if you're using `defer`, then the page is visible before the script loads and enables all the graphical components.
+Please note that if you're using `defer`, then the page is visible *before* the script loads.
 
-So, buttons should be disabled by CSS or by other means, to let the user
+So the user may read the page, but some graphical components are probably not ready yet.
+
+There should be "loading" indication in proper places, not-working buttons disabled, to clearly show the user what's ready and what's not.
+```
 
 In practice, `defer` is used for scripts that need the whole DOM and/or their relative execution order is important. And  `async` is used for independent scripts, like counters or ads. And their relative execution order does not matter.

6-data-storage/02-localstorage/article.md

@@ -42,9 +42,9 @@ localStorage.setItem('test', 1);
 alert( localStorage.getItem('test') ); // 1
 ```
 
-We only have to be on the same domain/port/protocol, the url path can be different.
+We only have to be on the same origin (domain/port/protocol), the url path can be different.
 
-The `localStorage` is shared, so if we set the data in one window, the change becomes visible in the other one.
+The `localStorage` is shared between all windows with the same origin, so if we set the data in one window, the change becomes visible in another one.
 
 ## Object-like access
 
@@ -73,7 +73,7 @@ That's allowed for historical reasons, and mostly works, but generally not recom
 
 ## Looping over keys
 
-As we've seen, the methods provide get/set/remove functionality. But how to get all saved values or keys?
+As we've seen, the methods provide "get/set/remove by key" functionality. But how to get all saved values or keys?
 
 Unfortunately, storage objects are not iterable.
 
@@ -198,7 +198,7 @@ Imagine, you have two windows with the same site in each. So `localStorage` is s
 You might want to open this page in two browser windows to test the code below.
 ```
 
-Now if both windows are listening for `window.onstorage`, then each one will react on updates that happened in the other one.
+If both windows are listening for `window.onstorage`, then each one will react on updates that happened in the other one.
 
 ```js run
 // triggers on updates made to the same storage from other documents
@@ -229,18 +229,18 @@ Web storage objects `localStorage` and `sessionStorage` allow to store key/value
 | `localStorage` | `sessionStorage` |
 |----------------|------------------|
 | Shared between all tabs and windows with the same origin | Visible within a browser tab, including iframes from the same origin |
-| Survives browser restart | Dies on tab close |
+| Survives browser restart | Survives page refresh (but not tab close) |
 
 API:
 
 - `setItem(key, value)` -- store key/value pair.
 - `getItem(key)` -- get the value by key.
 - `removeItem(key)` -- remove the key with its value.
 - `clear()` -- delete everything.
-- `key(index)` -- get the key on a given position.
+- `key(index)` -- get the key number `index`.
 - `length` -- the number of stored items.
 - Use `Object.keys` to get all keys.
-- Can use the keys as object properties, in that case `storage` event isn't triggered.
+- We access keys as object properties, in that case `storage` event isn't triggered.
 
 Storage event:
 

6-data-storage/03-indexeddb/article.md

@@ -16,11 +16,11 @@ That power is usually excessive for traditional client-server apps. IndexedDB is
 
 The native interface to IndexedDB, described in the specification <https://www.w3.org/TR/IndexedDB>, is event-based.
 
-We can also use `async/await` with the help of a promise-based wrapper, like <https://github.com/jakearchibald/idb>. That's pretty convenient, but the wrapper is not perfect, it can't replace events for all cases, so we'll start with events, and then use the wrapper.
+We can also use `async/await` with the help of a promise-based wrapper, like <https://github.com/jakearchibald/idb>. That's pretty convenient, but the wrapper is not perfect, it can't replace events for all cases. So we'll start with events, and  then, after we gain understanding of IndexedDb, we'll use the wrapper.
 
 ## Open database
 
-To start working with IndexedDB, we need to open a database.
+To start working with IndexedDB, we first need to open a database.
 
 The syntax:
 
@@ -31,16 +31,16 @@ let openRequest = indexedDB.open(name, version);
 - `name` -- a string, the database name.
 - `version` -- a positive integer version, by default `1` (explained below).
 
-We can have many databases with different names, all within the current origin (domain/protocol/port). So different websites can't access databases of each other.
+We can have many databases with different names, but all of them exist within the current origin (domain/protocol/port). Different websites can't access databases of each other.
 
 After the call, we need to listen to events on `openRequest` object:
-- `success`: database is ready, use the database object `openRequest.result` for further work.
+- `success`: database is ready, there's the "database object" in `openRequest.result`, that we should use it for further calls.
 - `error`: open failed.
 - `upgradeneeded`: database version is outdated (see below).
 
 **IndexedDB has a built-in mechanism of "schema versioning", absent in server-side databases.**
 
-Unlike server-side databases, IndexedDB is client-side, we don't have the data at hands. But when we publish a new version of our app, we may need to update the database.
+Unlike server-side databases, IndexedDB is client-side, in the browser, so we don't have the data at hands. But when we publish a new version of our app, we may need to update the database.
 
 If the local database version is less than specified in `open`, then a special event `upgradeneeded` is triggered, and we can compare versions and upgrade data structures as needed.
 
@@ -109,11 +109,13 @@ An example of object that can't be stored: an object with circular references. S
 
 **There must be an unique `key` for every value in the store.**     
 
-A key must have a type one of: number, date, string, binary, or array. It's a unique object identifier: we can search/remove/update values by the key.
+A key must have a type one of: number, date, string, binary, or array. It's an unique identifier: we can search/remove/update values by the key.
 
 ![](indexeddb-structure.png)
 
-We can provide a key when we add an value to the store, similar to `localStorage`. That's good for storing primitive values. But when we store objects, IndexedDB allows to setup an object property as the key, that's much more convenient. Or we can auto-generate keys.
+As we'll see very soon, we can provide a key when we add an value to the store, similar to `localStorage`. But when we store objects, IndexedDB allows to setup an object property as the key, that's much more convenient. Or we can auto-generate keys.
+
+But we need to create an object store first.
 
 The syntax to create an object store:
 ```js
@@ -127,7 +129,7 @@ Please note, the operation is synchronous, no `await` needed.
   - `keyPath` -- a path to an object property that IndexedDB will use as the key, e.g. `id`.
   - `autoIncrement` -- if `true`, then the key for a newly stored object is generated automatically, as an ever-incrementing number.
 
-If we don't supply any options, then we'll need to provide a key explicitly later, when storing an object.
+If we don't supply `keyOptions`, then we'll need to provide a key explicitly later, when storing an object.
 
 For instance, this object store uses `id` property as the key:
 ```js
@@ -136,22 +138,24 @@ db.createObjectStore('books', {keyPath: 'id'});
 
 **An object store can only be created/modified while updating the DB version, in `upgradeneeded` handler.**
 
-That's a technical limitation. Outside of the handler we'll be able to add/remove/update the data, but object stores are changed only during version update.
+That's a technical limitation. Outside of the handler we'll be able to add/remove/update the data, but object stores can be created/removed/altered only during version update.
+
+To perform database version upgrade, there are two main approaches:
+1. We can implement per-version upgrade functions: from 1 to 2, from 2 to 3, from 3 to 4 etc. Then, in `upgradeneeded` we can compare versions (e.g. old 2, now 4) and run per-version upgrades step by step, for every intermediate version (2 to 3, then 3 to 4).
+2. Or we can just examine the database: get a list of existing object stores as `db.objectStoreNames`. That object is a [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist) that provides `contains(name)` method to check for existance. And then we can do updates depending on what exists and what doesn't.
 
-To do an upgrade, there are two main ways:
-1. We can compare versions and run per-version operations.
-2. Or we can get a list of existing object stores as `db.objectStoreNames`. That object is a [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist), and it provides `contains(name)` method to check for the existance. And then we can do updates depending on what exists.
+For small databases the second path may be simpler.
 
 Here's the demo of the second approach:
 
 ```js
 let openRequest = indexedDB.open("db", 1);
 
-// create an object store for books if not exists
+// create/upgrade the database without version checks
 openRequest.onupgradeneeded = function() {
   let db = openRequest.result;
-  if (!db.objectStoreNames.contains('books')) {
-    db.createObjectStore('books', {keyPath: 'id'});
+  if (!db.objectStoreNames.contains('books')) { // if there's no "books" store
+    db.createObjectStore('books', {keyPath: 'id'}); // create it
   }
 };
 ```
@@ -188,14 +192,14 @@ db.transaction(store[, type]);
 - `store` is a store name that the transaction is going to access, e.g. `"books"`. Can be an array of store names if we're going to access multiple stores.
 - `type` – a transaction type, one of:
   - `readonly` -- can only read, the default.
-  - `readwrite` -- can only read and write, but not modify object stores.
+  - `readwrite` -- can only read and write the data, but not create/remove/alter object stores.
 
 There'is also `versionchange` transaction type: such transactions can do everything, but we can't create them manually. IndexedDB automatically creates a `versionchange` transaction when opening the database, for `updateneeded` handler. That's why it's a single place where we can update the database structure, create/remove object stores.
 
-```smart header="What are transaction types for?"
+```smart header="Why there exist different types of transactions?"
 Performance is the reason why transactions need to be labeled either `readonly` and `readwrite`.
 
-Many `readonly` transactions can access concurrently the same store, but `readwrite` transactions can't. A `readwrite` transaction "locks" the store for writing. The next transaction must wait before the previous one finishes before accessing the same store.
+Many `readonly` transactions are able to access concurrently the same store, but `readwrite` transactions can't. A `readwrite` transaction "locks" the store for writing. The next transaction must wait before the previous one finishes before accessing the same store.
 ```
 
 After the transaction is created, we can add an item to the store, like this:
@@ -227,12 +231,12 @@ request.onerror = function() {
 };
 ```
 
-There are basically four steps:
+There were basically four steps:
 
 1. Create a transaction, mention all stores it's going to access, at `(1)`.
 2. Get the store object using `transaction.objectStore(name)`, at `(2)`.
 3. Perform the request to the object store `books.add(book)`, at `(3)`.
-4. ...Handle request success/error `(4)`, make other requests if needed, etc.
+4. ...Handle request success/error `(4)`, then we can make other requests if needed, etc.
 
 Object stores support two methods to store a value:
 
@@ -242,30 +246,24 @@ Object stores support two methods to store a value:
 - **add(value, [key])**
     Same as `put`, but if there's already a value with the same key, then the request fails, and an error with the name `"ConstraintError"` is generated.
 
-Just like when opening a database, we send a request: `books.add(book)`, and then wait for `success/error` events.
+Similar to opening a database, we can send a request: `books.add(book)`, and then wait for `success/error` events.
 
 - The `request.result` for `add` is the key of the new object.
 - The error is in `request.error` (if any).
 
-## Transactions autocommit
+## Transactions' autocommit
 
-In the example above we started the transaction and made `add` request. We could make more requests. How do we finish ("commit") the transaction?
+In the example above we started the transaction and made `add` request. But as we stated previously, a transaction may have multiple associated requests, that must either all success or all fail. How do we mark the transaction as finished, no more requests to come?
 
 The short answer is: we don't.
 
 In the next version 3.0 of the specification, there will probably be a manual way to finish the transaction, but right now in 2.0 there isn't.
 
 **When all transaction requests are finished, and the [microtasks queue](info:microtask-queue) is empty, it is committed automatically.**
 
-```smart header="What's an \"empty microtask queue\"?"
-The microtask queue is explained in [another chapter](info:async-await#microtask-queue). In short, an empty microtask queue means that for all settled promises their `.then/catch/finally` handlers are executed.
+Usually, we can assume that a transaction commits when all its requests are complete, and the current code finishes.
 
-In other words, handling of finished promises and resuming "awaits" is done before closing the transaction.
-
-That's a minor technical detail. If we're using `async/await` instead of low-level promise calls, then we can assume that a transaction commits when all its requests are done, and the current code finishes.
-```
-
-So, in the example above no special code is needed to finish the transaction.
+So, in the example above no special call is needed to finish the transaction.
 
 Transactions auto-commit principle has an important side effect. We can't insert an async operation like `fetch`, `setTimeout` in the middle of transaction. IndexedDB will not keep the transaction waiting till these are done.
 
@@ -331,9 +329,9 @@ That's to be expected, not only because of possible errors at our side, but also
 
 **A failed request automatically aborts the transaction, canceling all its changes.**
 
-Sometimes a request may fail with a non-critical error. We'd like to handle it in `request.onerror` and continue the transaction. Then, to prevent the transaction abort, we should call `event.preventDefault()`.
+In some situations, we may want to handle the failure (e.g. try another request), without canceling existing changes, and continue the transaction. That's possible. The `request.onerror` handler is able to prevent the transaction abort by calling `event.preventDefault()`.
 
-In the example below a new book is added with the same key (`id`). The `store.add` method generates a `"ConstraintError"` in that case. We handle it without canceling the transaction:
+In the example below a new book is added with the same key (`id`) as the existing one. The `store.add` method generates a `"ConstraintError"` in that case. We handle it without canceling the transaction:
 
 ```js
 let transaction = db.transaction("books", "readwrite");
@@ -347,6 +345,7 @@ request.onerror = function(event) {
   if (request.error.name == "ConstraintError") {
     console.log("Book with such id already exists"); // handle the error
     event.preventDefault(); // don't abort the transaction
+    // use another key for the book?
   } else {
     // unexpected error, can't handle it
     // the transaction will abort
@@ -396,9 +395,9 @@ request.onerror = function(event) {
 
 ## Searching by keys
 
-There are two main ways to search in an object store:
+There are two main types of search in an object store:
 1. By a key or a key range. That is: by `book.id` in our "books" storage.
-2. By another object field, e.g. `book.price`. We need an index for that.
+2. By another object field, e.g. `book.price`.
 
 First let's deal with the keys and key ranges `(1)`.
 
@@ -524,7 +523,7 @@ Indexes are internally sorted by the tracked object field, `price` in our case.
 
 ## Deleting from store
 
-The `delete` method looks up values to delete by a query, just like `getAll`.
+The `delete` method looks up values to delete by a query, the call format is similar to `getAll`:
 
 - **`delete(query)`** -- delete matching values by query.
 
@@ -555,9 +554,7 @@ books.clear(); // clear the storage.
 
 Methods like `getAll/getAllKeys` return an array of keys/values.
 
-But an object storage can be huge, bigger than the available memory.
-
-Then `getAll` will fail to get all records as an array.
+But an object storage can be huge, bigger than the available memory. Then `getAll` will fail to get all records as an array.
 
 What to do?
 
@@ -608,7 +605,7 @@ request.onsuccess = function() {
 The main cursor methods are:
 
 - `advance(count)` -- advance the cursor `count` times, skipping values.
-- `continue([key])` -- advance the cursor to the next value in range matching or after key.
+- `continue([key])` -- advance the cursor to the next value in range matching (or immediately after `key` if given).
 
 Whether there are more values matching the cursor or not -- `onsuccess` gets called, and then in `result` we can get the cursor pointing to the next record, or `undefined`.
 
@@ -672,7 +669,7 @@ So we have all the sweet "plain async code" and "try..catch" stuff.
 
 ### Error handling
 
-If we don't catch the error, then it falls through, just as usual.
+If we don't catch an error, then it falls through, till the closest outer `try..catch`.
 
 An uncaught error becomes an "unhandled promise rejection" event on `window` object.
 
@@ -688,7 +685,7 @@ window.addEventListener('unhandledrejection', event => {
 
 ### "Inactive transaction" pitfall
 
-A we know already, a transaction auto-commits as soon as the browser is done with the current code and microtasks. So if we put an *macrotask* like `fetch` in the middle of a transaction, then the transaction won't wait for it to finish. It just auto-commits. So the next request in it fails.
+A we know already, a transaction auto-commits as soon as the browser is done with the current code and microtasks. So if we put an *macrotask* like `fetch` in the middle of a transaction, then the transaction won't wait for it to finish. It just auto-commits. So the next request in it would fail.
 
 For a promise wrapper and `async/await` the situation is the same.
 

9-regular-expressions/10-regexp-backreferences/article.md

@@ -1,6 +1,6 @@
 # Backreferences in pattern: \n and \k
 
-Capturing groups can be accessed not only in the result or in the replacement string, but also in the pattern itself.
+We can use the contents of capturing groups `(...)` not only in the result or in the replacement string, but also in the pattern itself.
 
 ## Backreference by number: \n
 
@@ -12,7 +12,7 @@ We need to find a quoted string: either a single-quoted `subject:'...'` or a dou
 
 How to look for them?
 
-We can put two kinds of quotes in the pattern: `pattern:['"](.*?)['"]`, but it would find strings with mixed quotes, like `match:"...'` and `match:'..."`. That would lead to incorrect matches when one quote appears inside other ones, like the string `subject:"She's the one!"`:
+We can put both kinds of quotes in the square brackets: `pattern:['"](.*?)['"]`, but it would find strings with mixed quotes, like `match:"...'` and `match:'..."`. That would lead to incorrect matches when one quote appears inside other ones, like the string `subject:"She's the one!"`:
 
 ```js run
 let str = `He said: "She's the one!".`;
@@ -25,7 +25,7 @@ alert( str.match(reg) ); // "She'
 
 As we can see, the pattern found an opening quote `match:"`, then the text is consumed lazily till the other quote `match:'`, that closes the match.
 
-To make sure that the pattern looks for the closing quote exactly the same as the opening one, we can make a groups of it and use the backreference.
+To make sure that the pattern looks for the closing quote exactly the same as the opening one, we can wrap it into a capturing group and use the backreference.
 
 Here's the correct code: