From c69411014a2c013e4177756b5d71a50fcd836b8b Mon Sep 17 00:00:00 2001 From: Bogdan Bacosca Date: Fri, 9 Dec 2022 06:55:51 +0200 Subject: [PATCH 1/5] line 45 improved readability --- 2-ui/99-ui-misc/03-event-loop/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md index 3ea0c2c571..1505a4e018 100644 --- a/2-ui/99-ui-misc/03-event-loop/article.md +++ b/2-ui/99-ui-misc/03-event-loop/article.md @@ -42,7 +42,7 @@ So far, quite simple, right? Two more details: 1. Rendering never happens while the engine executes a task. It doesn't matter if the task takes a long time. Changes to the DOM are painted only after the task is complete. -2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an alert like "Page Unresponsive", suggesting killing the task with the whole page. That happens when there are a lot of complex calculations or a programming error leading to an infinite loop. +2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an alert like "Page Unresponsive", suggesting killing the task with the whole page. That happens when a lot of complex calculations take place or when a programming error leads to an infinite loop. That was the theory. Now let's see how we can apply that knowledge. From 1bab640e9a17eb0be3ab1b98f1820b79e26707db Mon Sep 17 00:00:00 2001 From: Bogdan Bacosca Date: Fri, 9 Dec 2022 07:02:35 +0200 Subject: [PATCH 2/5] line 53 minor improvement in describing the flow of ideas --- 2-ui/99-ui-misc/03-event-loop/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md index 1505a4e018..d5033fc308 100644 --- a/2-ui/99-ui-misc/03-event-loop/article.md +++ b/2-ui/99-ui-misc/03-event-loop/article.md @@ -50,7 +50,7 @@ That was the theory. Now let's see how we can apply that knowledge. Let's say we have a CPU-hungry task. -For example, syntax-highlighting (used to colorize code examples on this page) is quite CPU-heavy. To highlight the code, it performs the analysis, creates many colored elements, adds them to the document -- for a large amount of text that takes a lot of time. +For example, syntax-highlighting (used to colorize code examples on this page) is quite CPU-heavy. To highlight the code, the engine performs an analysis, creates many colored elements, then adds them to the document -- for a large amount of text that takes a lot of time. While the engine is busy with syntax highlighting, it can't do other DOM-related stuff, process user events, etc. It may even cause the browser to "hiccup" or even "hang" for a bit, which is unacceptable. From f75c5e48904530ac9b75b69c4c9412b9ce88b6d7 Mon Sep 17 00:00:00 2001 From: Bogdan Bacosca Date: Mon, 12 Dec 2022 13:05:01 +0200 Subject: [PATCH 3/5] line 263 no , before the word and. Reads `.then` runs after current core. --- 2-ui/99-ui-misc/03-event-loop/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md index d5033fc308..ed26ca9dc1 100644 --- a/2-ui/99-ui-misc/03-event-loop/article.md +++ b/2-ui/99-ui-misc/03-event-loop/article.md @@ -260,7 +260,7 @@ alert("code"); What's going to be the order here? 1. `code` shows first, because it's a regular synchronous call. -2. `promise` shows second, because `.then` passes through the microtask queue, and runs after the current code. +2. `promise` shows second, because `.then` passes through the microtask queue and runs after the current code. 3. `timeout` shows last, because it's a macrotask. The richer event loop picture looks like this (order is from top to bottom, that is: the script first, then microtasks, rendering and so on): From 7fd59c421722172703d2c4e169e4026188c65979 Mon Sep 17 00:00:00 2001 From: Bogdan Bacosca Date: Mon, 12 Dec 2022 18:10:10 +0200 Subject: [PATCH 4/5] line 323 fixed missing : --- 2-ui/99-ui-misc/03-event-loop/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md index ed26ca9dc1..a41a62e341 100644 --- a/2-ui/99-ui-misc/03-event-loop/article.md +++ b/2-ui/99-ui-misc/03-event-loop/article.md @@ -320,7 +320,7 @@ That may be used to split a big calculation-heavy task into pieces, for the brow Also, used in event handlers to schedule an action after the event is fully handled (bubbling done). -To schedule a new *microtask* +To schedule a new *microtask*: - Use `queueMicrotask(f)`. - Also promise handlers go through the microtask queue. From c0d6a3f4d077ba1d15b0b6906eedabeb94c87914 Mon Sep 17 00:00:00 2001 From: Bogdan Bacosca Date: Wed, 14 Dec 2022 12:43:11 +0200 Subject: [PATCH 5/5] updated line 45 taking the PR comments into account --- 2-ui/99-ui-misc/03-event-loop/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md index a41a62e341..cea5419b67 100644 --- a/2-ui/99-ui-misc/03-event-loop/article.md +++ b/2-ui/99-ui-misc/03-event-loop/article.md @@ -42,7 +42,7 @@ So far, quite simple, right? Two more details: 1. Rendering never happens while the engine executes a task. It doesn't matter if the task takes a long time. Changes to the DOM are painted only after the task is complete. -2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an alert like "Page Unresponsive", suggesting killing the task with the whole page. That happens when a lot of complex calculations take place or when a programming error leads to an infinite loop. +2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an "Page Unresponsive" alert, suggesting to kill the task along with the whole page. That happens when a lot of complex calculations take place or when a programming error leads to an infinite loop. That was the theory. Now let's see how we can apply that knowledge.