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

Update article.md

Browse source 
Small fixes.
This commit is contained in:
Peter Kampjes 2020-07-26 21:35:32 -03:00 • committed by GitHub
parent b0464bb32c
commit ed78e2602d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

11
2-ui/2-events/05-dispatch-events/article.md
View file

@ -187,7 +187,6 @@ Any handler can listen for that event with `rabbit.addEventListener('hide',...)`
<button onclick="hide()">Hide()</button> <button onclick="hide()">Hide()</button>
<script> <script>
// hide() will be called automatically in 2 seconds
function hide() { function hide() {
let event = new CustomEvent("hide", { let event = new CustomEvent("hide", {
cancelable: true // without that flag preventDefault doesn't work cancelable: true // without that flag preventDefault doesn't work
@ -211,13 +210,13 @@ Please note: the event must have the flag `cancelable: true`, otherwise the call
## Events-in-events are synchronous ## Events-in-events are synchronous
Usually events are processed in a queue. That is: if the browser is processing `onclick` and a new event occurs, e.g. mouse moved, then it's handing is queued up, corresponding `mousemove` handlers will be called after `onclick` processing is finished. Usually events are processed in a queue. That is: if the browser is processing `onclick` and a new event occurs, e.g. mouse moved, then it's handling is queued up, corresponding `mousemove` handlers will be called after `onclick` processing is finished.
The notable exception is when one event is initiated from within another one, e.g. using `dispatchEvent`. Such events are processed immediately: the new event handlers are called, and then the current event handling is resumed. The notable exception is when one event is initiated from within another one, e.g. using `dispatchEvent`. Such events are processed immediately: the new event handlers are called, and then the current event handling is resumed.
For instance, in the code below the `menu-open` event is triggered during the `onclick`. For instance, in the code below the `menu-open` event is triggered during the `onclick`.
It's processed immediately, without waiting for `onlick` handler to end: It's processed immediately, without waiting for `onclick` handler to end:
```html run autorun ```html run autorun
@ -243,7 +242,7 @@ The output order is: 1 -> nested -> 2.
Please note that the nested event `menu-open` is caught on the `document`. The propagation and handling of the nested event is finished before the processing gets back to the outer code (`onclick`). Please note that the nested event `menu-open` is caught on the `document`. The propagation and handling of the nested event is finished before the processing gets back to the outer code (`onclick`).
That's not only about `dispatchEvent`, there are other cases. If an event handler calls methods that trigger to other events -- they are too processed synchronously, in a nested fashion. That's not only about `dispatchEvent`, there are other cases. If an event handler calls methods that trigger other events -- they too are processed synchronously, in a nested fashion.
Let's say we don't like it. We'd want `onclick` to be fully processed first, independently from `menu-open` or any other nested events. Let's say we don't like it. We'd want `onclick` to be fully processed first, independently from `menu-open` or any other nested events.
@ -283,9 +282,9 @@ Other constructors of native events like `MouseEvent`, `KeyboardEvent` and so on
For custom events we should use `CustomEvent` constructor. It has an additional option named `detail`, we should assign the event-specific data to it. Then all handlers can access it as `event.detail`. For custom events we should use `CustomEvent` constructor. It has an additional option named `detail`, we should assign the event-specific data to it. Then all handlers can access it as `event.detail`.
Despite the technical possibility to generate browser events like `click` or `keydown`, we should use with the great care. Despite the technical possibility of generating browser events like `click` or `keydown`, we should use them with great care.
We shouldn't generate browser events as it's a hacky way to run handlers. That's a bad architecture most of the time. We shouldn't generate browser events as it's a hacky way to run handlers. That's bad architecture most of the time.
Native events might be generated: Native events might be generated: