replace side-effect with side effect
This commit is contained in:
parent
291b5c05b9
commit
4aa9f818e8
10 changed files with 10 additions and 10 deletions
|
@ -268,7 +268,7 @@ for (let i = 0; i < 10; i++) {
|
||||||
|
|
||||||
From a technical point of view, this is identical to the example above. Surely, we can just wrap the code in an `if` block instead of using `continue`.
|
From a technical point of view, this is identical to the example above. Surely, we can just wrap the code in an `if` block instead of using `continue`.
|
||||||
|
|
||||||
But as a side-effect, this created one more level of nesting (the `alert` call inside the curly braces). If the code inside of `if` is longer than a few lines, that may decrease the overall readability.
|
But as a side effect, this created one more level of nesting (the `alert` call inside the curly braces). If the code inside of `if` is longer than a few lines, that may decrease the overall readability.
|
||||||
````
|
````
|
||||||
|
|
||||||
````warn header="No `break/continue` to the right side of '?'"
|
````warn header="No `break/continue` to the right side of '?'"
|
||||||
|
|
|
@ -139,7 +139,7 @@ switch (a) {
|
||||||
|
|
||||||
Now both `3` and `5` show the same message.
|
Now both `3` and `5` show the same message.
|
||||||
|
|
||||||
The ability to "group" cases is a side-effect of how `switch/case` works without `break`. Here the execution of `case 3` starts from the line `(*)` and goes through `case 5`, because there's no `break`.
|
The ability to "group" cases is a side effect of how `switch/case` works without `break`. Here the execution of `case 3` starts from the line `(*)` and goes through `case 5`, because there's no `break`.
|
||||||
|
|
||||||
## Type matters
|
## Type matters
|
||||||
|
|
||||||
|
|
|
@ -522,7 +522,7 @@ function name(parameters, delimited, by, comma) {
|
||||||
|
|
||||||
To make the code clean and easy to understand, it's recommended to use mainly local variables and parameters in the function, not outer variables.
|
To make the code clean and easy to understand, it's recommended to use mainly local variables and parameters in the function, not outer variables.
|
||||||
|
|
||||||
It is always easier to understand a function which gets parameters, works with them and returns a result than a function which gets no parameters, but modifies outer variables as a side-effect.
|
It is always easier to understand a function which gets parameters, works with them and returns a result than a function which gets no parameters, but modifies outer variables as a side effect.
|
||||||
|
|
||||||
Function naming:
|
Function naming:
|
||||||
|
|
||||||
|
|
|
@ -232,7 +232,7 @@ setTimeout(function() {...}, 100);
|
||||||
|
|
||||||
For `setInterval` the function stays in memory until `clearInterval` is called.
|
For `setInterval` the function stays in memory until `clearInterval` is called.
|
||||||
|
|
||||||
There's a side-effect. A function references the outer lexical environment, so, while it lives, outer variables live too. They may take much more memory than the function itself. So when we don't need the scheduled function anymore, it's better to cancel it, even if it's very small.
|
There's a side effect. A function references the outer lexical environment, so, while it lives, outer variables live too. They may take much more memory than the function itself. So when we don't need the scheduled function anymore, it's better to cancel it, even if it's very small.
|
||||||
````
|
````
|
||||||
|
|
||||||
## Zero delay setTimeout
|
## Zero delay setTimeout
|
||||||
|
|
|
@ -272,7 +272,7 @@ In other words:
|
||||||
- module scripts wait until the HTML document is fully ready (even if they are tiny and load faster than HTML), and then run.
|
- module scripts wait until the HTML document is fully ready (even if they are tiny and load faster than HTML), and then run.
|
||||||
- relative order of scripts is maintained: scripts that go first in the document, execute first.
|
- relative order of scripts is maintained: scripts that go first in the document, execute first.
|
||||||
|
|
||||||
As a side-effect, module scripts always "see" the fully loaded HTML-page, including HTML elements below them.
|
As a side effect, module scripts always "see" the fully loaded HTML-page, including HTML elements below them.
|
||||||
|
|
||||||
For instance:
|
For instance:
|
||||||
|
|
||||||
|
|
|
@ -154,7 +154,7 @@ Move the mouse over the input field to see `clientX/clientY` (the example is in
|
||||||
|
|
||||||
## Preventing selection on mousedown
|
## Preventing selection on mousedown
|
||||||
|
|
||||||
Double mouse click has a side-effect that may be disturbing in some interfaces: it selects text.
|
Double mouse click has a side effect that may be disturbing in some interfaces: it selects text.
|
||||||
|
|
||||||
For instance, double-clicking on the text below selects it in addition to our handler:
|
For instance, double-clicking on the text below selects it in addition to our handler:
|
||||||
|
|
||||||
|
|
|
@ -100,7 +100,7 @@ ball.style.left = pageX - ball.offsetWidth / 2 + 'px';
|
||||||
ball.style.top = pageY - ball.offsetHeight / 2 + 'px';
|
ball.style.top = pageY - ball.offsetHeight / 2 + 'px';
|
||||||
```
|
```
|
||||||
|
|
||||||
Not bad, but there's a side-effect. To initiate the drag'n'drop, we can `mousedown` anywhere on the ball. But if "take" it from its edge, then the ball suddenly "jumps" to become centered under the mouse pointer.
|
Not bad, but there's a side effect. To initiate the drag'n'drop, we can `mousedown` anywhere on the ball. But if "take" it from its edge, then the ball suddenly "jumps" to become centered under the mouse pointer.
|
||||||
|
|
||||||
It would be better if we keep the initial shift of the element relative to the pointer.
|
It would be better if we keep the initial shift of the element relative to the pointer.
|
||||||
|
|
||||||
|
|
|
@ -149,7 +149,7 @@ The `onkeydown` handler here uses `checkPhoneKey` to check for the key pressed.
|
||||||
|
|
||||||
As we know, the `false` value returned from the event handler, assigned using a DOM property or an attribute, such as above, prevents the default action, so nothing appears in the `<input>` for keys that don't pass the test. (The `true` value returned doesn't affect anything, only returning `false` matters)
|
As we know, the `false` value returned from the event handler, assigned using a DOM property or an attribute, such as above, prevents the default action, so nothing appears in the `<input>` for keys that don't pass the test. (The `true` value returned doesn't affect anything, only returning `false` matters)
|
||||||
|
|
||||||
Please note that special keys, such as `key:Backspace`, `key:Left`, `key:Right`, do not work in the input. That's a side-effect of the strict filter `checkPhoneKey`. These keys make it return `false`.
|
Please note that special keys, such as `key:Backspace`, `key:Left`, `key:Right`, do not work in the input. That's a side effect of the strict filter `checkPhoneKey`. These keys make it return `false`.
|
||||||
|
|
||||||
Let's relax the filter a little bit by allowing arrow keys `key:Left`, `key:Right` and `key:Delete`, `key:Backspace`:
|
Let's relax the filter a little bit by allowing arrow keys `key:Left`, `key:Right` and `key:Delete`, `key:Backspace`:
|
||||||
|
|
||||||
|
|
|
@ -154,7 +154,7 @@ Depending on your browser, the `iframe` above is either empty or alerting you th
|
||||||
|
|
||||||
## Showing with disabled functionality
|
## Showing with disabled functionality
|
||||||
|
|
||||||
The `X-Frame-Options` header has a side-effect. Other sites won't be able to show our page in a frame, even if they have good reasons to do so.
|
The `X-Frame-Options` header has a side effect. Other sites won't be able to show our page in a frame, even if they have good reasons to do so.
|
||||||
|
|
||||||
So there are other solutions... For instance, we can "cover" the page with a `<div>` with styles `height: 100%; width: 100%;`, so that it will intercept all clicks. That `<div>` is to be removed if `window == top` or if we figure out that we don't need the protection.
|
So there are other solutions... For instance, we can "cover" the page with a `<div>` with styles `height: 100%; width: 100%;`, so that it will intercept all clicks. That `<div>` is to be removed if `window == top` or if we figure out that we don't need the protection.
|
||||||
|
|
||||||
|
|
|
@ -101,7 +101,7 @@ For each URL generated by `URL.createObjectURL` the browser stores a URL -> `Blo
|
||||||
|
|
||||||
A generated URL (and hence the link with it) is only valid within the current document, while it's open. And it allows to reference the `Blob` in `<img>`, `<a>`, basically any other object that expects a URL.
|
A generated URL (and hence the link with it) is only valid within the current document, while it's open. And it allows to reference the `Blob` in `<img>`, `<a>`, basically any other object that expects a URL.
|
||||||
|
|
||||||
There's a side-effect though. While there's a mapping for a `Blob`, the `Blob` itself resides in the memory. The browser can't free it.
|
There's a side effect though. While there's a mapping for a `Blob`, the `Blob` itself resides in the memory. The browser can't free it.
|
||||||
|
|
||||||
The mapping is automatically cleared on document unload, so `Blob` objects are freed then. But if an app is long-living, then that doesn't happen soon.
|
The mapping is automatically cleared on document unload, so `Blob` objects are freed then. But if an app is long-living, then that doesn't happen soon.
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue