You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/11-async/07-microtask-queue/article.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -30,17 +30,17 @@ As said in the [specification](https://tc39.github.io/ecma262/#sec-jobs-and-job-
30
30
- The queue is first-in-first-out: tasks enqueued first are run first.
31
31
- Execution of a task is initiated only when nothing else is running.
32
32
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.
34
34
35
35
That's why "code finished" in the example above shows first.
36
36
37
37

38
38
39
-
Promise handlers always go through that internal queue.
39
+
Promise handlers always go through this internal queue.
40
40
41
41
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.
42
42
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`?**
44
44
45
45
Easy, just put it into the queue with `.then`:
46
46
@@ -54,7 +54,7 @@ Now the order is as intended.
54
54
55
55
## Unhandled rejection
56
56
57
-
Remember `unhandledrejection` event from the chapter <info:promise-error-handling>?
57
+
Remember the `unhandledrejection` event from the chapter <info:promise-error-handling>?
58
58
59
59
Now we can see exactly how JavaScript finds out that there was an unhandled rejection
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`.
97
97
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!".
99
99
100
100
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.
0 commit comments