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

minor

Browse source
This commit is contained in:
Ilya Kantor 2019-06-18 16:10:00 +03:00
parent 3578cb3135
commit 9b95b5ee0e
2 changed files with 17 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

8
1-js/12-generators-iterators/2-async-iterators-generators/article.md
View file

@ -112,7 +112,7 @@ Here's a small cheatsheet:
| | Iterators | Async iterators | | | Iterators | Async iterators |
|-------|-----------|-----------------| |-------|-----------|-----------------|
| Object method to provide iteraterable | `Symbol.iterator` | `Symbol.asyncIterator` | | Object method to provide iterator | `Symbol.iterator` | `Symbol.asyncIterator` |
| `next()` return value is | any value | `Promise` | | `next()` return value is | any value | `Promise` |
| to loop, use | `for..of` | `for await..of` | | to loop, use | `for..of` | `for await..of` |
@ -178,7 +178,7 @@ No problem, just prepend it with `async`, like this:
})(); })();
``` ```
Now we have an the async generator, iteratable with `for await...of`. Now we have an the async generator, iterable with `for await...of`.
It's indeed very simple. We add the `async` keyword, and the generator now can use `await` inside of it, rely on promises and other async functions. It's indeed very simple. We add the `async` keyword, and the generator now can use `await` inside of it, rely on promises and other async functions.
@ -344,7 +344,7 @@ Syntax differences between async and regular iterators:
| | Iterators | Async iterators | | | Iterators | Async iterators |
|-------|-----------|-----------------| |-------|-----------|-----------------|
| Object method to provide iteraterable | `Symbol.iterator` | `Symbol.asyncIterator` | | Object method to provide iterator | `Symbol.iterator` | `Symbol.asyncIterator` |
| `next()` return value is | any value | `Promise` | | `next()` return value is | any value | `Promise` |
Syntax differences between async and regular generators: Syntax differences between async and regular generators:
@ -356,6 +356,6 @@ Syntax differences between async and regular generators:
In web-development we often meet streams of data, when it flows chunk-by-chunk. For instance, downloading or uploading a big file. In web-development we often meet streams of data, when it flows chunk-by-chunk. For instance, downloading or uploading a big file.
We can use async generators to process such data, but it's worth to mention that there's also another API called Streams, that provides special interfaces to transform the data and to pass it from one stream to another (e.g. download from one place and immediately send elsewhere). We can use async generators to process such data, but it's worth to mention that there's also another API called Streams, that provides special interfaces to transform the data and to pass it from one stream to another (e.g. download from one place and immediately send elsewhere).
Streams API not a part of JavaScript language standard. Streams and async generators complement each other, both are great ways to handle async data flows. Streams API not a part of JavaScript language standard. Streams and async generators complement each other, both are great ways to handle async data flows.

26
2-ui/1-document/10-size-and-scroll-window/article.md
View file

@ -17,11 +17,11 @@ For instance, this button shows the height of your window:
``` ```
````warn header="Not `window.innerWidth/Height`" ````warn header="Not `window.innerWidth/Height`"
Browsers also support properties `window.innerWidth/innerHeight`. They look like what we want. So what's the difference? Browsers also support properties `window.innerWidth/innerHeight`. They look like what we want. So why not to use them instead?
If there's a scrollbar occupying some space, `clientWidth/clientHeight` provide the width/height inside it. In other words, they return width/height of the visible part of the document, available for the content. If there exists a scrollbar, and it occupies some space, `clientWidth/clientHeight` provide the width/height without it (subtract it). In other words, they return width/height of the visible part of the document, available for the content.
And `window.innerWidth/innerHeight` ignore the scrollbar. ...And `window.innerWidth/innerHeight` ignore the scrollbar.
If there's a scrollbar, and it occupies some space, then these two lines show different values: If there's a scrollbar, and it occupies some space, then these two lines show different values:
```js run ```js run
@ -42,9 +42,9 @@ In modern HTML we should always write `DOCTYPE`. Generally that's not a JavaScri
Theoretically, as the root document element is `documentElement.clientWidth/Height`, and it encloses all the content, we could measure its full size as `documentElement.scrollWidth/scrollHeight`. Theoretically, as the root document element is `documentElement.clientWidth/Height`, and it encloses all the content, we could measure its full size as `documentElement.scrollWidth/scrollHeight`.
These properties work well for regular elements. But for the whole page these properties do not work as intended. In Chrome/Safari/Opera if there's no scroll, then `documentElement.scrollHeight` may be even less than `documentElement.clientHeight`! For regular elements that's a nonsense. These properties work well for regular elements. But for the whole page these properties do not work as intended. In Chrome/Safari/Opera if there's no scroll, then `documentElement.scrollHeight` may be even less than `documentElement.clientHeight`! Sounds like a nonsense, weird, right?
To have a reliable result on the full document height, we should take the maximum of these properties: To reliably obtain the full document height, we should take the maximum of these properties:
```js run ```js run
let scrollHeight = Math.max( let scrollHeight = Math.max(
@ -60,11 +60,11 @@ Why so? Better don't ask. These inconsistencies come from ancient times, not a "
## Get the current scroll [#page-scroll] ## Get the current scroll [#page-scroll]
Regular elements have their current scroll state in `elem.scrollLeft/scrollTop`. DOM elements have their current scroll state in `elem.scrollLeft/scrollTop`.
What's with the page? Most browsers provide `documentElement.scrollLeft/Top` for the document scroll, but Chrome/Safari/Opera have bugs (like [157855](https://code.google.com/p/chromium/issues/detail?id=157855), [106133](https://bugs.webkit.org/show_bug.cgi?id=106133)) and we should use `document.body` instead of `document.documentElement` there. For document scroll `document.documentElement.scrollLeft/Top` works in most browsers, except oldler WebKit-based ones, like Safari (bug [5991](https://bugs.webkit.org/show_bug.cgi?id=5991)), where we should use `document.body` instead of `document.documentElement` there.
Luckily, we don't have to remember these peculiarities at all, because of the special properties `window.pageXOffset/pageYOffset`: Luckily, we don't have to remember these peculiarities at all, because the scroll is available in the special properties `window.pageXOffset/pageYOffset`:
```js run ```js run
alert('Current scroll from the top: ' + window.pageYOffset); alert('Current scroll from the top: ' + window.pageYOffset);
@ -83,11 +83,11 @@ For instance, if we try to scroll the page from the script in `<head>`, it won't
Regular elements can be scrolled by changing `scrollTop/scrollLeft`. Regular elements can be scrolled by changing `scrollTop/scrollLeft`.
We can do the same for the page: We can do the same for the page, but as explained above:
- For all browsers except Chrome/Safari/Opera: modify `document.documentElement.scrollTop/Left`. - For most browsers (except older Webkit-based) `document.documentElement.scrollTop/Left` is the right property.
- In Chrome/Safari/Opera: use `document.body.scrollTop/Left` instead. - Otherwise, `document.body.scrollTop/Left`.
It should work, but smells like cross-browser incompatibilities. Not good. Fortunately, there's a simpler, more universal solution: special methods [window.scrollBy(x,y)](mdn:api/Window/scrollBy) and [window.scrollTo(pageX,pageY)](mdn:api/Window/scrollTo). These cross-browser incompatibilities are not good. Fortunately, there's a simpler, universal solution: special methods [window.scrollBy(x,y)](mdn:api/Window/scrollBy) and [window.scrollTo(pageX,pageY)](mdn:api/Window/scrollTo).
- The method `scrollBy(x,y)` scrolls the page relative to its current position. For instance, `scrollBy(0,10)` scrolls the page `10px` down. - The method `scrollBy(x,y)` scrolls the page relative to its current position. For instance, `scrollBy(0,10)` scrolls the page `10px` down.
@ -96,7 +96,7 @@ It should work, but smells like cross-browser incompatibilities. Not good. Fortu
<button onclick="window.scrollBy(0,10)">window.scrollBy(0,10)</button> <button onclick="window.scrollBy(0,10)">window.scrollBy(0,10)</button>
``` ```
- The method `scrollTo(pageX,pageY)` scrolls the page relative to the document's top-left corner. It's like setting `scrollLeft/scrollTop`. - The method `scrollTo(pageX,pageY)` scrolls the page to absolute coordinates, so that the top-left corner of the visible part has coordinates `(pageX, pageY)` relative to the document's top-left corner. It's like setting `scrollLeft/scrollTop`.
To scroll to the very beginning, we can use `scrollTo(0,0)`. To scroll to the very beginning, we can use `scrollTo(0,0)`.