From 05dfb567867c96e0e0f5e2afc7e15b43faedb2bf Mon Sep 17 00:00:00 2001 From: Vse Mozhe Buty Date: Sun, 1 Nov 2020 18:59:36 +0200 Subject: [PATCH] Fix typo, add note in 1.12.2 (Async iteration) --- .../2-async-iterators-generators/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/12-generators-iterators/2-async-iterators-generators/article.md b/1-js/12-generators-iterators/2-async-iterators-generators/article.md index 10375f63..00a56b9c 100644 --- a/1-js/12-generators-iterators/2-async-iterators-generators/article.md +++ b/1-js/12-generators-iterators/2-async-iterators-generators/article.md @@ -301,7 +301,7 @@ Now values come with a delay of 1 second between them. ```smart Technically, we can add both `Symbol.iterator` and `Symbol.asyncIterator` to the object, so it's both synchronously (`for..of`) and asynchronously (`for await..of`) iterable. -In practice though, that would be an weird thing to do. +In practice though, that would be a weird thing to do. ``` ## Real-life example: paginated data @@ -363,7 +363,7 @@ More explanations about how it works: - The initial URL is `https://api.github.com/repos//commits`, and the next page will be in the `Link` header of the response. - The `fetch` method allows us to supply authorization and other headers if needed -- here GitHub requires `User-Agent`. 2. The commits are returned in JSON format. -3. We should get the next page URL from the `Link` header of the response. It has a special format, so we use a regular expression for that. +3. We should get the next page URL from the `Link` header of the response. It has a special format, so we use a regular expression for that (we will lern this feature in [Regular expressions](info:regular-expressions)). - The next page URL may look like `https://api.github.com/repositories/93253246/commits?page=2`. It's generated by GitHub itself. 4. Then we yield the received commits one by one, and when they finish, the next `while(url)` iteration will trigger, making one more request.