Skip to content

Commit 1257501

Browse files
authored
Update article.md
Grammar suggestions, one rephrase
1 parent df58d3f commit 1257501

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

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

+6-6
Original file line numberDiff line numberDiff line change
@@ -30,17 +30,17 @@ As said in the [specification](https://tc39.github.io/ecma262/#sec-jobs-and-job-
3030
- The queue is first-in-first-out: tasks enqueued first are run first.
3131
- Execution of a task is initiated only when nothing else is running.
3232

33-
Or, to say that simply, when a promise is ready, its `.then/catch/finally` handlers are put into the queue. They are not executed yet. JavaScript engine takes a task from the queue and executes it, when it becomes free from the current code.
33+
Or, to say that simply, when a promise is ready, its `.then/catch/finally` handlers are put into the queue. They are not executed yet. When the JavaScript engine becomes free from the current code, it takes a task from the queue and executes it.
3434

3535
That's why "code finished" in the example above shows first.
3636

3737
![](promiseQueue.svg)
3838

39-
Promise handlers always go through that internal queue.
39+
Promise handlers always go through this internal queue.
4040

4141
If there's a chain with multiple `.then/catch/finally`, then every one of them is executed asynchronously. That is, it first gets queued, and executed when the current code is complete and previously queued handlers are finished.
4242

43-
**What if the order matters for us? How can we make `code finished` work after `promise done`?**
43+
**What if the order matters for us? How can we make `code finished` run after `promise done`?**
4444

4545
Easy, just put it into the queue with `.then`:
4646

@@ -54,7 +54,7 @@ Now the order is as intended.
5454

5555
## Unhandled rejection
5656

57-
Remember `unhandledrejection` event from the chapter <info:promise-error-handling>?
57+
Remember the `unhandledrejection` event from the chapter <info:promise-error-handling>?
5858

5959
Now we can see exactly how JavaScript finds out that there was an unhandled rejection
6060

@@ -93,9 +93,9 @@ setTimeout(() => promise.catch(err => alert('caught')), 1000);
9393
window.addEventListener('unhandledrejection', event => alert(event.reason));
9494
```
9595

96-
Now, if you run it, we'll see `Promise Failed!` message first, and then `caught`.
96+
Now, if you run it, we'll see `Promise Failed!` first and then `caught`.
9797

98-
If we didn't know about microtasks queue, we could wonder: "Why did `unhandledrejection` handler run? We did catch the error!".
98+
If we didn't know about the microtasks queue, we could wonder: "Why did `unhandledrejection` handler run? We did catch the error!".
9999

100100
But now we understand that `unhandledrejection` is generated when the microtask queue is complete: the engine examines promises and, if any of them is in "rejected" state, then the event triggers.
101101

0 commit comments

Comments
 (0)