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>
<script>
// hide() will be called automatically in 2 seconds
function hide() {
let event = new CustomEvent("hide", {
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
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.
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
@ -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`).
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.
@ -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`.
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: